[FFmpeg-devel] [PATCH 1/2] lavf: make max_analyze_duration warning an information log.
Clément Bœsch
ubitux at gmail.com
Sat Jan 28 01:49:14 CET 2012
On Sat, Jan 28, 2012 at 12:14:31AM +0100, Michael Niedermayer wrote:
> On Fri, Jan 27, 2012 at 10:34:51PM +0100, Clément Bœsch wrote:
> > On Fri, Jan 27, 2012 at 10:31:26PM +0100, Michael Niedermayer wrote:
> > > On Fri, Jan 27, 2012 at 09:53:24PM +0100, Clément Bœsch wrote:
> > > > On Thu, Jan 26, 2012 at 03:15:59PM +0100, Michael Niedermayer wrote:
> > > > > On Thu, Jan 26, 2012 at 01:53:43PM +0100, Clément Bœsch wrote:
> > > > > > This avoids the confusion of having a warning almost everytime we are
> > > > > > probing a mp3. It may suppose the file is not muxed correctly while it
> > > > > > is actually a normal behaviour.
> > > > >
> > > > > why is the code not exiting earlier ?
> > > > > what information is missing for that ?
> > > > >
> > > > > It would be better to return earlier because it reduces startup
> > > > > latency
> > > > >
> > > >
> > > > It seems to trigger the st->first_dts == AV_NOPTS_VALUE check. After a
> > > > talk with Hendrik on IRC, a potential solution would have be to do
> > > > something like:
> > > >
> > > > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > > > index b5ed83e..96daf5c 100644
> > > > --- a/libavformat/mp3dec.c
> > > > +++ b/libavformat/mp3dec.c
> > > > @@ -197,6 +197,6 @@ AVInputFormat ff_mp3_demuxer = {
> > > > .read_probe = mp3_read_probe,
> > > > .read_header = mp3_read_header,
> > > > .read_packet = mp3_read_packet,
> > > > - .flags= AVFMT_GENERIC_INDEX,
> > > > + .flags = AVFMT_GENERIC_INDEX | AVFMT_NOTIMESTAMPS,
> > > > .extensions = "mp2,mp3,m2a", /* XXX: use probe */
> > > > };
> > > > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > > > index c1de71d..090fdff 100644
> > > > --- a/libavformat/utils.c
> > > > +++ b/libavformat/utils.c
> > > > @@ -2474,8 +2474,11 @@ int avformat_find_stream_info(AVFormatContext *ic, AVDictionary **options)
> > > > break;
> > > > if(st->parser && st->parser->parser->split && !st->codec->extradata)
> > > > break;
> > > > - if(st->first_dts == AV_NOPTS_VALUE && (st->codec->codec_type == AVMEDIA_TYPE_VIDEO || st->codec->codec_type == AVMEDIA_TYPE_AUDIO))
> > > > + if(st->first_dts == AV_NOPTS_VALUE &&
> > > > + !(ic->iformat->flags & AVFMT_NOTIMESTAMPS) &&
> > > > + (st->codec->codec_type == AVMEDIA_TYPE_VIDEO || st->codec->codec_type == AVMEDIA_TYPE_AUDIO)) {
> > > > break;
> > > > + }
> > > > }
> > > > if (i == ic->nb_streams) {
> > > > /* NOTE: if the format has no header, then we need to read
> > > >
> > > >
> > > > But this breaks at least some DTS detection doing the same with MP3
> > > > (seek-mp2).
> > > >
> > > > Any hint on how to fix this properly are welcome.
> > >
> > > can you post the diff from the seektest failur ?
> > >
> >
> > Sure:
> >
> > --- ./tests/ref/seek/mp2_mp2 2011-01-18 21:10:05.123248731 +0100
> > +++ tests/data/fate/seek-mp2_mp2 2012-01-27 21:25:56.926199589 +0100
> > @@ -1,6 +1,6 @@
> > -ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 0 size: 417
> > +ret: 0 st: 0 flags:1 dts: NOPTS pts: NOPTS pos: 0 size: 417
> > ret: 0 st:-1 flags:0 ts:-1.000000
> > -ret: 0 st: 0 flags:1 dts: 0.026122 pts: 0.026122 pos: 417 size: 418
> > +ret: 0 st: 0 flags:1 dts: 0.000000 pts: 0.000000 pos: 0 size: 417
> > ret: 0 st:-1 flags:1 ts: 1.894167
> > ret: 0 st: 0 flags:1 dts: 1.880816 pts: 1.880816 pos: 30093 size: 418
> > ret: 0 st: 0 flags:0 ts: 0.788334
> >
> > Note that FATE passes when I do the same with the FLAC.
>
> you could try setting cur_dts = 0 in read_header of mp3
>
This seems not be needed (and doesn't fix anything); in avformat_new_stream():
/* we set the current DTS to 0 so that formats without any timestamps
but durations get some timestamps, formats with some unknown
timestamps have their first few packets buffered and the
timestamps corrected before they are returned to the user */
st->cur_dts = 0;
Also, I'm concerned about cur_dts being under "#if FF_API_REORDER_PRIVATE"…
[...]
--
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120128/b2c1f403/attachment.asc>
More information about the ffmpeg-devel
mailing list