[FFmpeg-devel] [PATCH] avformat: export probe score

[Michael Niedermayer]

On Fri, Aug 09, 2013 at 07:15:00AM +0200, Reimar Döffinger wrote:
> Paul B Mahol <onemda at gmail.com> wrote:
> >On 8/9/13, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> On Thu, Aug 08, 2013 at 09:44:44PM +0000, Paul B Mahol wrote:
> >>> On 8/8/13, Michael Niedermayer <michaelni at gmx.at> wrote:
> >>> > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> >>> > ---
> >>> >  libavformat/avformat.h      |   17 +++++++++++++++--
> >>> >  libavformat/options_table.h |    1 +
> >>> >  libavformat/utils.c         |   18 ++++++++++++++----
> >>> >  3 files changed, 30 insertions(+), 6 deletions(-)
> >>> >
> >>> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >>> > index d5f8a29..6afdcf5 100644
> >>> > --- a/libavformat/avformat.h
> >>> > +++ b/libavformat/avformat.h
> >>> > @@ -1237,6 +1237,13 @@ typedef struct AVFormatContext {
> >>> >       */
> >>> >      int flush_packets;
> >>> >
> >>> > +    /**
> >>> > +     * format probing score
> >>> > +     * - encoding: unused
> >>> > +     * - decoding: set by avformat, read by user via AVOPtions
> >(NO
> >>> > direct
> >>> > access)
> >>> > +     */
> >>> > +    int probe_score;
> >>> > +
> >>>
> >>> Should't this above be bellow?
> >>
> >> it is intended to be public API, so i would say no
> >
> >But than it would break with fork, wouldn't it?
> >
> >>
> >> [...]
> >>> > diff --git a/libavformat/options_table.h
> >b/libavformat/options_table.h
> >>> > index a87868e..cf7f2da 100644
> >>> > --- a/libavformat/options_table.h
> >>> > +++ b/libavformat/options_table.h
> >>> > @@ -76,6 +76,7 @@ static const AVOption avformat_options[] = {
> >>> >  {"skip_initial_bytes", "skip initial bytes",
> >>> > OFFSET(skip_initial_bytes),
> >>> > AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX-1, D},
> >>> >  {"correct_ts_overflow", "correct single timestamp overflows",
> >>> > OFFSET(correct_ts_overflow), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1,
> >D},
> >>> >  {"flush_packets", "enable flushing of the I/O context after each
> >>> > packet",
> >>> > OFFSET(flush_packets), AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, E},
> >>> > +{"probe_score", "score with which the format was probed",
> >>> > OFFSET(probe_score), AV_OPT_TYPE_INT, {.i64 = 0}, 0,
> >AVPROBE_SCORE_MAX,
> >>> > D},
> >>>
> >>> Hmm? What is this suppose to do?
> >>
> >> allow the user to find out the score by which some container was
> >> detected/probed
> >
> >But those are used primarly to set values by caller.
> >Yes I know that we do not care for consistency at all.
> >
> >At least there should be separation between read-only options - for
> >caller pov and others.
> >As changing this value doesn't makes sense for user.
> 
> Should it be read-only though?
> For the probe function you'd actually pass in a minimum score needed to detect a format. Might actually be useful for command-line uses of FFmpeg itself where people can't add their own code after all...

it could be usefull but iam not sure using the same field for this
is a good idea. Its clearer if a field is just written to by one side

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/20130827/d4b9cc96/attachment.asc>