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

[D Richard Felker III]

On Fri, Aug 01, 2003 at 10:50:20PM +0200, Arpi wrote:
> Hi,
> 
> > > > any better ideas?
> > > 
> > > IMO it should be much simpler than this. If the frames are being
> > > dropped at the codec/demuxer end (because of 0-byte skipped frames in
> > > .avi container and such, or nonrecoverable decoding errors or
> > > whatever) then the codec/demuxer layer or the wrapper between codec
> > > and vf layer should just adjust the relative_pts of the next frame it
> > > sends out to account for any dropped frames in between.
> > 
> > > On the other hand, if the frames are being dropped by a filter, it
> > > seems to me that the filter should be responsible for pts accounting.
> > > This is already the case for filters like inverse telecine that don't
> > > actually 'drop' frames, but which have a non-1-to-1 correspondence
> > > between input and output frames, so it seems like it'd be ok for other
> > > filters (dint, decimate, etc.) which drop frames to do the same.
> > 
> > you're right, as usual :)
> > i'll go for this.
> 
> I felt there will be some problems you didn't think of...
> 
> For a start, there are cases, when only the codec can determine the actual
> PTS & duration (be it raw mpeg4 stream, or realvideo, or mpeg1/2),
> but frame dropping (soft -framedrop) is enabled. SO, for B frames the codec
> will return NULL (no iamge decoding done) so the PTS/duration info lost.

Not sure about other codecs, but with lavc you should be able to ask
it to parse the frame (and thus get pts info) without actually
decoding. It's hurry_up==5 or something. Not sure how well this fits
in with mplayer's codec/demuxer architecture tho...

> One possible solution would be to make codec optionally handle PTS info.
> In this case the codec should take care of PTS calculation for next
> non-dropped frame (ie. adjusting its rel_pts).
> 
> Another method would be let codecs don't support frame dropping.
> (most codecs don't support it anyway, as no B frames or such thing)
> This could be flagged by a flag in either codec's global frams (see
> codecs.conf) or module_info_t flags. Maybe the former is better, for
> things like win32 dlls, where some dll support it some not.
> For codecs with no framedroping ability, the vf_vd.c could calculate
> the PTS correction, for the rest the codec should take care of.
> 
> Both way seems doable, but adds extra compelxity to the already
> complicated stuff.
> 
> Better ideas?

Not really. Basically framedropping sucks. :(


Rich