[FFmpeg-devel] base av_read_frame() function for seeking in mpegps files
Thu Jul 23 19:21:50 CEST 2009
2009/7/16 Ivan Schreter <schreter at gmx.net>
> Michael Niedermayer wrote:
>> On Wed, Jul 15, 2009 at 11:07:04AM +0800, zhentan feng wrote:
>>> Well, its to be expected that the first frame that the parser outputs
>>>> incomplete, after seeking
>>> Is this a bug or just keep it like this?
>> It can be seen as both bug and as correct depending on how one looks at
> I personally see this as a bug.
> so when I find this frame, but get the wrong size,
>>> should I return the next correct frame with the correct size or just
>>> this frame with the wrong size?
>> I guess from an end user POV there should be no incomplete frame after
>> seeking, ideally ...
> See above - IMHO a bug, if it returns incomplete frame.
> But please note that the file must be positioned at appropriate point so
> that all contained streams synchronize at timestamp passed (at least in new
> seeking API). I've implemented fix for MPEG-TS to seek properly. The
> function to find a point in file to synchronize all streams based on a rough
> position is also implemented. But this depends on the parser returning
> complete frames _and_ correct position from where to read the frame to
> re-read it (this is the position of first PES packet of a frame in MPEG-TS,
> I didn't study MPEG-PS how it's coded there).
> See my last patch I sent about week and half ago. You might reuse the
> positioning routine (I've put in lavf/utils.c). It is not yet committed,
> though. I'll ping the maintainers.
> Actually, I've tried to add also seeking routines in mpeg.c based on my
> patch, but the seeking doesn't work correctly, since parser doesn't return
> proper positions, I suppose (I didn't have time to analyze further). See
> attached patch for mpeg.c (NOT working) and seeking patches for lavf/utils
> and mpegts (working for MPEG-TS). I didn't include seek regression patch
> here, see my other post to get it clean, if you want to test.
> I am little confused about how to handle this situation.
>> Well ...
>> Whats clear to me is that
>> * Parsers should not discard data on normal playback
>> * Iam not sure if Parsers should attempt to drop the first incomplete
>> frame after seeking or if that can be done at a common point for
>> all affected parsers.
>> * The end user should not receive an incomplete frame after seeking in
>> an undamaged stream, thats ideally, its not really an issue if its
>> too hard to achive
> I'd propose to drop incomplete frame, as this might irritate the decoder
> printing unnecessary warnings. I don't think it's too complicated here, as
> this could be handled by my filtering routine, provided positions of
> following frames returned are correct.
> I also would like to drop the first incomplete frame, but is there any way
to fix it?
I am not clear why the parser return the wrong frame size when fist call
av_read_frame() after seek.
anyone explain it futher?
More information about the ffmpeg-devel