[FFmpeg-devel] base av_read_frame() function for seeking in mpegps files

[zhentan feng]

Hi

2009/7/16 Ivan Schreter <schreter at gmx.net>

> Hi,
>
> 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
>>>> might
>>>> be
>>>> 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
>> it.
>>
>>
> 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
>>> return
>>> 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?

zhentan
thanks
-- 
Best wishes~