[FFmpeg-devel] [PATCH 1/2] lavf: make max_analyze_duration warning an information log.

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120128/53b8e19c/attachment.asc>