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

[Ivan Schreter]

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.

Regards,

Ivan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: seek_uncooked_mpeg.patch
Type: text/x-patch
Size: 2859 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090715/fa279de1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: seek_cooked_lavf.patch
Type: text/x-patch
Size: 20084 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090715/fa279de1/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: seek_cooked_mpegts.patch
Type: text/x-patch
Size: 3367 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090715/fa279de1/attachment-0002.bin>