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

Michael Niedermayer michaelni
Sat Jul 25 10:44:33 CEST 2009


On Fri, Jul 24, 2009 at 01:21:50AM +0800, zhentan feng wrote:
> 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?

mpeg PS/TS stores frames randomly distributed into packets. when you seek the
first frame thus returned by the demuxer will most likely not be complete
the parser doesnt drop it, so it returns a incomplete frame.
If it did drop it after seeking you still would receive a different first
frame compared to normal playback as it wasnt incomplete in that case

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
-------------- 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/20090725/e723b027/attachment.pgp>



More information about the ffmpeg-devel mailing list