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

[Michael Niedermayer]

On Tue, Aug 27, 2013 at 10:01:57PM +0000, Paul B Mahol wrote:
> On 8/27/13, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Tue, Aug 27, 2013 at 09:45:02PM +0000, Paul B Mahol wrote:
> >> 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.
> >
> > please elaborate
> 
> You are adding extra inconsistency by adding '(NO direct access)'.
> 
> What that means? Is it same as text bellow?
> If it is internal, why all internal stuff can not be documented
> as such in clear and consistent way.

"No direct access" means code outside libavformat is not allowed to
access the field like mystruct.field

Internal means that code outside libavformat is not supposed to access
the field in any way

the "direct access" thing is just a artifact of inter-fork
compatibility, it doesnt mean anything semantically about what is
public and what is internal

If someone has suggestions on how to better document that ...


> 
> >
> >
> >>
> >> If something is internal it should be documented as such.
> >
> > absolutely, yes
> >
> >
> >>
> >> But looks like some developers like to play games with users.
> >
> > please elaborate
> 
> See above.
> 
> >
> > [...]
> >
> > --
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker.
> > User
> > questions about the command line tools should be sent to the ffmpeg-user
> > ML.
> > And questions about how to use libav* should be sent to the libav-user ML.
> >
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.
-------------- 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/20130828/a0601a96/attachment.asc>