Performance requirements inherent in streaming mpeg2
cworley at symbionsys.com
Tue May 22 16:51:45 CEST 2001
Is their a problem inherent to streaming (vs. file oriented) mpeg2 that makes it
difficult to drop frames when trying to playback in realtime?
I'm running on a 200Mhz Pentium (please chuckle).
The performance bottleneck for viewing mpeg2 in realtime seems to be the
decoding (not the network/filesystem, not the display).
Of all the mpeg2 decoders I've tried (mplayer, mpeg12play, xine, etc...)
mpeg2dec and vlc seem to be the best (robustness and performance).
mpeg2dec is the only player that will play from stdin, but it won't drop frames
when it can't keep up with the frame rate; it just playsback slowly. This isn't
a display problem, I can easily change it to only display 1/n frames, but that
doesn't increase the performance significantly for either the sdl or x11 output
Vlc will play from a file, and drop frames as necessary, but won't use stdin.
Vlc has a streaming network interface (driven by vlms or vls). When I use the
network interface, vlc acts like mpeg2dec: plays slowly, won't drop frames.
I'm sure one reason mpeg2dec won't drop frames is that it's used for things
other than direct display that don't require realtime playback but do require
that all the video is played.
But, given that both programs have this "problem", it seems that there might be
an inability to drop frames that is inherent to streaming (vs. file oriented)
mpeg2. Is this correct? If so, what's the problem?
More information about the vlc-devel