Re: bypassing PTS in video filter layer
Arpi <[email protected]>
| Newsgroups | gmane.comp.video.mplayer.g2.devel |
|---|---|
| Message-ID | <[email protected]> |
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. 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? A'rpi / Astral & ESP-team -- Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu