[FFmpeg-devel] [PATCH] print message if probe failed due to probe conflict

[Michael Niedermayer]

On Fri, Sep 25, 2009 at 03:08:28PM +0200, Reimar D?ffinger wrote:
> On Fri, Sep 25, 2009 at 02:55:49PM +0200, Michael Niedermayer wrote:
> > On Fri, Sep 25, 2009 at 02:41:40PM +0200, Reimar D?ffinger wrote:
> > > On Fri, Sep 25, 2009 at 02:33:29PM +0200, Michael Niedermayer wrote:
> > > > On Fri, Sep 25, 2009 at 02:11:38PM +0200, Reimar D?ffinger wrote:
> > > > > If two probe functions return the same value, it is a bit hard to find
> > > > > out which ones were involved and broke things.
> > > > > So I propose this:
> > > > 
> > > > does your code work?
> > > > it looks to me like it would print a warning if 3 demuxers return
> > > > 1
> > > > 1
> > > > 90
> > > > but not if they return 
> > > > 1
> > > > 90
> > > > 1
> > > > 
> > > > simply printing all scores and piping through sort -n seems more usefull
> > > > to me in this case ...
> > > 
> > > It was not supposed to print anything in both cases, if forgot to check
> > > for fmt == NULL. I don't mean it as a test tool for conflicting probe
> > > values, but as an actually useful message for users, only for the case
> > > where probing actually fails.
> > 
> > Your code still does not look like it would work
> > especially as a user understandable warning because when probe fails the
> > probe buffer is increased until some limit, conflicts at > 25 can happen
> > and trigger your warning while in the next round probe can succeed without
> > conflict as one or more probes are than able to return more accurate
> > scores.
> 
> That would only leave checking one level higher up, though that gives
> hardly any useful information:
> Index: libavformat/utils.c
> ===================================================================
> --- libavformat/utils.c (revision 20013)
> +++ libavformat/utils.c (working copy)
> @@ -453,6 +453,7 @@
>      /* Do not open file if the format does not need it. XXX: specific
>         hack needed to handle RTSP/TCP */
>      if (!fmt || !(fmt->flags & AVFMT_NOFILE)) {
> +        int score;
>          /* if no file needed do not try to open one */
>          if ((err=url_fopen(&pb, filename, URL_RDONLY)) < 0) {
>              goto fail;
> @@ -462,7 +463,7 @@
>          }
>  
>          for(probe_size= PROBE_BUF_MIN; probe_size<=PROBE_BUF_MAX && !fmt; probe_size<<=1){
> -            int score= probe_size < PROBE_BUF_MAX ? AVPROBE_SCORE_MAX/4 : 0;
> +            score= probe_size < PROBE_BUF_MAX ? AVPROBE_SCORE_MAX/4 : 0;
>              /* read probe data */
>              pd->buf= av_realloc(pd->buf, probe_size + AVPROBE_PADDING_SIZE);
>              pd->buf_size = get_buffer(pb, pd->buf, probe_size);
> @@ -484,6 +485,9 @@
>                      av_log(logctx, AV_LOG_DEBUG, "Probed with size=%d and score=%d\n", probe_size, score);
>              }
>          }
> +        if (!fmt && score > 0)
> +            av_log(logctx, AV_LOG_WARNING, "No format match due to probe conflict with score %i\n", score);
> +
>          av_freep(&pd->buf);
>      }
>  
> 
> However maybe my previous patch as AV_LOG_DEBUG only as debugging help
> would be better?
> It would not catch all probe conflicts, only those that lead to probe
> failure at a given buffer size, and it would "spam" in cases where probe
> succeeds with larger probe buffer, but seems better than nothing.

it may be better than nothing but i dont see how it would be better than
score=x->probe()
if(score){
    av_log(score > 25 ? AV_LOG_INFO : AV_LOG_DEBUG, "score:%d %s %dbytes",  score, name, size);
}
piped through sort -n it will show all conflicts at debug, and more

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch
-------------- 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/20090925/bbf13e0c/attachment.pgp>