Performance requirements inherent in streaming mpeg2

Chris Worley cworley at
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 mailing list