[FFmpeg-devel] [PATCH] Fix MPEG-TS seek and frame positions in general

Michael Niedermayer michaelni
Wed Feb 18 00:58:55 CET 2009

On Mon, Feb 16, 2009 at 06:14:01PM -0800, Baptiste Coudurier wrote:
> Hi,
> Ivan Schreter wrote:
> > Ivan Schreter wrote:
> >> Ivan Schreter wrote:
> >>   
> >>> Ivan Schreter wrote:
> >>>   
> >>>     
> >>>> [...]
> >>>> Patch #5: mpegts seek only searches for a PES packet with correct pid 
> >>>> and existing DTS and relies on this being a key frame. This is not 
> >>>> even the case in the test file. Read frames via av_read_frame until a 
> >>>> key frame is found and return position/timestamp of this frame. This 
> >>>> needs #1 to reset the packet reader after reading the frames, so 
> >>>> further reads work correctly, #2 to have correct positions from mpegts 
> >>>> and #4 to have exact position of the packet for later file seek.
> >>>>     
> If I understand correctly, this seems to be a general issue with
> read_timestamp which does not honor the key frame request.

originally read_timestamp() was supposed to always saerch for a keyframe
and only return its pos&timestamp. If it did that seeking would work alot
more reliable ...
but this had a flaw i did not fully realize originally, namely that
doing it that way needs O(keyframe_distance * log filesize)
while first searching for a timestamp and then secondly for a keyframe
needs O(packet_distance * log filesize + keyframe_distance)
so because its better and faster read_timestamp() ignores keyframes
sadly the 2nd step (keyframe search) is missing ...

also for the new seek API we need to not only find one keyframe of one
stream but one keyframe for each active stream and in both directions
then from this decide where to seek to. Sounds nasty but shouldnt be
because it doesnt cost to consider more streams ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090218/676c011e/attachment.pgp>

More information about the ffmpeg-devel mailing list