[FFmpeg-devel] seeking in ts (was: mpegvideo_parser outputs incomplete frames)

Michael Niedermayer michaelni
Wed Sep 5 14:25:35 CEST 2007


On Tue, Sep 04, 2007 at 09:49:51PM -0000, Wolfram Gloger wrote:
> Hi,
> > Date: Mon, 3 Sep 2007 00:28:40 +0200
> > From: Michael Niedermayer <michaelni at gmx.at>
> > On Sun, Sep 02, 2007 at 09:33:02PM -0000, Wolfram Gloger wrote:
> > >=20
> > > Well I want/need to call av_find_stream_info() after the seek (stream
> > > parameters might have changed a lot after a seek in ts), and at the
> > > end of that we have
> > 
> > could we maybe rather work on the truncated frame issue without dragging
> > this into your highly controversal view of how to use av_find_stream_info()
> Ok, first things first.  av_find_stream_info() is really a different
> issue (though I think a majority would expect that to be callable
> anywhere within the stream, if not it should be clearly documented).

the problem is not so much if av_find_stream_info() can or cannot be
called in the middle of a stream but rather that there should not be
any need to

the parameters of an existing AVStream MUST NOT change if they do the
mpeg ts demuxer is buggy it should rather create a new stream

> > and to return to the original question, do or do not the patches change
> > seeking behavior in ts
> They do change the seeking behaviour with regard to what happens
> _after_ a seek -- I have already posted the changes for the seek
> regression test -- but IMHO they only change the fact that the first
> frame isn't always labeled as a key frame any more.
> > question is just if it gets worse due to the patches
> I have not seen any new issues due to these except that in the frame
> copy case the "drop initial non-keyframe" code in ffmpeg.c now really
> comes into action and it can lead to the following output:
> (video frame dropped)
> audio frame
> audio frame
> audio frame...
> (video frame dropped)
> audio frame
> audio frame
> audio frame...
> video frame (first real I frame)
> audio frame...
> so we have up to 0.4 seconds of audio before the first video frame
> arrives and e.g. dvdauthor doesn't like that.  I have a workaround for
> that but for now I'd just like to point that out as the only new
> problem I've seen.

if thats the only issue, thats ok

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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/20070905/235febb9/attachment.pgp>

More information about the ffmpeg-devel mailing list