[FFmpeg-devel] [PATCH] move put_v from nutenc.c and make it public in avio.h and aviobuf.c

Michael Chinen mchinen
Thu Jul 8 02:53:47 CEST 2010


2010/7/8 M?ns Rullg?rd <mans at mansr.com>:
> Michael Chinen <mchinen at gmail.com> writes:
>
>> 2010/7/8 M?ns Rullg?rd <mans at mansr.com>:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>
>>>> On Thu, Jul 08, 2010 at 12:17:05AM +0100, M?ns Rullg?rd wrote:
>>>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>>>
>>>>> > On Wed, Jul 07, 2010 at 11:00:56PM +0100, M?ns Rullg?rd wrote:
>>>>> >> Michael Chinen <mchinen at gmail.com> writes:
>>>>> >>
>>>>> >> > --- a/libavformat/avio.h
>>>>> >> > +++ b/libavformat/avio.h
>>>>> >> > @@ -352,12 +352,12 @@ void put_strz(ByteIOContext *s, const char *buf);
>>>>> >> > ?/**
>>>>> >> > ? * Put val using a variable number of bytes.
>>>>> >> > ? */
>>>>> >> > -void put_v(ByteIOContext *bc, uint64_t val);
>>>>> >> > +void ff_put_v(ByteIOContext *bc, uint64_t val);
>>>>> >> >
>>>>> >> > ?/**
>>>>> >> > ? * Get the length in bytes which is needed to store val as v.
>>>>> >> > ? */
>>>>> >> > -int get_length(uint64_t val);
>>>>> >> > +int ff_get_v_length(uint64_t val);
>>>>> >>
>>>>> >> Since this is a public header, wouldn't an av_ prefix be appropriate?
>>>>> >
>>>>> > i dont think we are planing to use them from outside lavf so it should be ff_
>>>>>
>>>>> They seem useful enough, but whatever.
>>>>
>>>> i dont mind making them public if someone wants to use them
>>>> iam not aware of anyone wanting that though
>>>
>>> Let's keep them private for now then. ?It's easy enough to change
>>> later if we want to. ?The opposite is not true.
>> Ok. ?To be clear, private here means ff_ prefix in avio.h?
>
> No, it means ff_ prefix in some private header. ?avio.h is a public
> header, so it's a bad place for private stuff.
I understand now.  I thought maybe there was some convention where ff_
and non-av_ prefixes in public headers meant clients shouldn't use
those and pretend they were private.

I see the logic but want to note this will create some inconsistency
since the read counterpart for these functions (ff_get_v) is already
public in avio.h.   If this is okay I'll put ff_put_v and
ff_get_v_length in internal.h/aviobuf.c.  On the other hand if we want
to make them public I accidentally made the patches :)

Michael



More information about the ffmpeg-devel mailing list