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

Paul B Mahol onemda at gmail.com
Tue Aug 27 23:45:02 CEST 2013


On 8/27/13, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Aug 09, 2013 at 05:10:09AM +0000, Paul B Mahol 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?
>
> it should not break it, the fields afterwards are internal to lavf
> also there are already ffmpeg specific fields there

Following yet another breaking of consistency.

If something is internal it should be documented as such.

But looks like some developers like to play games with users.

>
>
>>
>> >
>> > [...]
>> >> > 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.
>
> The difference is in the flags, i had forgotten to set it correctly
> in the patch, fixed locally

I really want to see such patch. As I doubt its doable with current code.

>
>
>> As changing this value doesn't makes sense for user.
>
> yes
>
>>
>> >
>> > [...]
>> > --
>> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>> >
>> > Many that live deserve death. And some that die deserve life. Can you
>> > give
>> > it to them? Then do not be too eager to deal out death in judgement.
>> > For
>> > even the very wise cannot see all ends. -- Gandalf
>> >
>>
>> Hah
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 3
> "Rare item" - "Common item with rare defect or maybe just a lie"
> "Professional" - "'Toy' made in china, not functional except as doorstop"
> "Experts will know" - "The seller hopes you are not an expert"
>


More information about the ffmpeg-devel mailing list