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

Michael Niedermayer michaelni
Wed Jul 15 09:20:59 CEST 2009


On Wed, Jul 15, 2009 at 11:07:04AM +0800, zhentan feng wrote:
> Hi
> 
> 2009/7/15 Michael Niedermayer <michaelni at gmx.at>
> 
> > On Thu, Jul 09, 2009 at 05:36:48PM +0800, zhentan feng wrote:
> > > Hi
> > >
> > > I am implementing a seek api for mpegps demuxer.
> > > Index entries are already built before seeking, the frame pos is set as
> > PES
> > > header pos.
> > >
> > > so when seek target timestamp,
> > > 1) look up the index and get the frame pos in the index entries.
> > > 2) use url_fseek() seek to the pos and call av_read_frame() until get the
> > > target frame
> > >
> > > here I have an error: the target frame size is not correct for some
> > > situation, ie not same with the actual frame size, but the pts/dts value
> > is
> > > correct.
> >
> > 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.


> 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 ...


> 
> 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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/20090715/db71d819/attachment.pgp>



More information about the ffmpeg-devel mailing list