Re: bypassing PTS in video filter layer

Hi,

> Perhaps we should have 3 or 4 levels of framedrop, instead of 2 like

yes

> 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.

It is really big hack, and simply doesn't worth it to implement.
There are several issues:
- needs big hacks in demuxers
- formats using short keyframe rate, also mostly uses (easily droppable)
  B frames. it's true in general, that there are 2 kind of
  containers/codecs, one for live streaming (no B frames, big keyframe distance,
  no seeking, no cpu usage scalability, no backward (or speed!=1x) playback)
  and one for offline playback and editing, like mpeg (short keyframe/gop
  distance, B frames, and so on, the opposite of the other).
- it's not completely true that I frames are keyframes in mpeg2. there are
  streams (actually most of them i've seen) using partial update in I frames,
  ie. you need to decode 2 or more I frames to get the complete picture,
  otherwise you'll see checkboard-liek thing. just try to seek in some mpeg2
  streams... (mostly true for DVD and DVB files). I frames don't use
  prediction (ie. reference frames), so you can seek to them, but also don't
  always cover the whole image area, so you can't simply skip them.

And anwyay, as you already mentioned: framedropping sucks.
We shouldn't optimize our player for frame dropping (esp. at times of 2.6ghz
p4 cpus being used even for word processing machines) but for speed and
quality.


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu