[MPlayer-G2-dev] bypassing PTS in video filter layer

D Richard Felker III dalias at aerifal.cx
Fri Aug 1 23:35:28 CEST 2003

On Fri, Aug 01, 2003 at 08:53:23PM +0200, Arpi wrote:
> but for slow-cpu (and also slow-vga) type framedrop i think it's
> more than a filter. actually it's a drop signal to the codec to do decoding
> as fast as possible (ie. skip B frames, postprocessing etc) and skip all teh
> filtering and display. The special case of temporal filters is already
> hdnaled in the vf_process_image(), ie. drop 'signal' is not delivered above
> the last filter needing all frames.

Well I think there are two different problems we're addressing here.
One is where the cpu is actually too slow to play the movie at all,
and you have to recover as much cpu time as possible. The other case
is where the cpu is plenty fast to decode all frames, but video memory
is very slow, or else you're software scaling the movie to fullscreen.

In the first case, it makes sense to skip decoding B frames entirely
and maybe even skip some P frames (hardframedrop). But for the latter
case, where scale/vo is taking all the cpu time, it would be nice to
decode ALL frames so that temporal filters get to see all the frames,
and then only start dropping somewhere midway down the filter chain
(i.e. before scale, equalizer, or other slow spatial-only filters).

Perhaps we should have 3 or 4 levels of framedrop, instead of 2 like
in G1:

1. Decode all frames, drop some with a filter if vf/vo is too slow.
2. Decode all I/P frames but skip B frames and filter chain if video
   gets behind (like -framedrop now).
3. (optional, big hack) Like 2, but use some sort of lookahead in
   demuxer layer to identify when we're getting close to a new I
   frame, and drop one or two P frames just before it. This probably
   wouldn't help divx but might be nice for DVD/VCD where keyframe
   interval is small.
4. Full -hardframedrop.


More information about the MPlayer-G2-dev mailing list