[FFmpeg-devel] [PATCH] Some lavf renames

[Baptiste Coudurier]

Hi,

Stefano Sabatini wrote:
> On date Wednesday 2009-01-21 09:40:25 +0100, Benoit Fouet encoded:
>> Hi,
>>
>> On 01/21/2009 03:40 AM, Michael Niedermayer wrote:
>>> On Tue, Jan 20, 2009 at 11:40:37PM +0100, Stefano Sabatini wrote:
>>>   
>>>> On date Tuesday 2009-01-20 12:09:20 -0800, Baptiste Coudurier encoded:
>>>>     
>>>>> Hi Ramiro,
>>>>>
>>>>> Ramiro Polla wrote:
>>>>>       
>>>>>> On Tue, Jan 20, 2009 at 6:00 PM, Baptiste Coudurier
>>>>>> <baptiste.coudurier at gmail.com> wrote:
>>>>>>         
>>>>>>> Hi Stefano,
>>>>>>>
>>>>>>> Stefano Sabatini wrote:
>>>>>>>           
>>>>>>>> On date Friday 2009-01-09 01:44:00 +0100, Diego Biurrun encoded:
>>>>>>>>             
>>>>>>>>> On Thu, Jan 08, 2009 at 10:59:40PM +0100, Stefano Sabatini wrote:
>>>>>>>>>               
>>>>>>>>>> attached patches propose the renames:
>>>>>>>>>> av_alloc_format_context -> avformat_alloc_context (more similar to avcodec_alloc_context)
>>>>>>>>>>
>>>>>>>>>> av_register_all -> avformat_register_all (avcodec_register_all, avfilter_register_all, avdevice_register_all)
>>>>>>>>>>                 
>>>>>>>>> FWIW, I'm in favor..
>>>>>>>>>               
>>>>>>>> Ping.
>>>>>>>>             
>>>>>>> I'm in favor too, also some attention could be paid to "guess_format" :>
>>>>>>>           
>>>>>> Wasn't there some discussion some time ago about renaming a bunch of
>>>>>> functions? I think if we're going to rename some functions, we might
>>>>>> as well rename all functions to be consistent and break API only once.
>>>>>>         
>>>>> Yes, indeed. We will break API during next major dump, this is not going
>>>>> to happen anytime soon.
>>>>>       
>>>> I propose also these renames, people can add to the list:
>>>>
>>>> lavc:
>>>> register_avcodec          -> avcodec_register()
>>>>
>>>> lavf:
>>>>     
>>>   
>>>> ff_reduce_index           -> av_reduce_index
>>>>     
>>> exporting internal API does not belong in a renaming patch
>>>
>>>
>>>   
>>>> av_register_input_format  -> avformat_register_input
>>>> av_register_output_format -> avformat_register_output
>>>> av_iformat_next           -> avformat_next_input
>>>> av_oformat_next           -> avformat_next_output
>>>>     
>>> i abstain from voting for a color but must note that you guys should
>>> also consider that every rename will mean every app that use the function
>>> needs to be updated, not sure if this justifies this cleanup.
>>> Maybe it does but if i where maintaining some app i likely would be
>>> primarely pissed about every rename that i had to deal with ...
>>> But then its no big deal, if people want it, do the rename ...
>>>
>>>   
>> maybe  we can come up with one of the following solutions:
>>  - #define av_register_input_format avformat_register_input
>>  - #define avformat_register_input av_register_input_format
> [...]
> 
> If you want to drop those names using macros is not the way to go,
> since they can't be deprecated neither documented.
> 
> Putting a reference in the old functions docs to the new one and
> deprecating the old ones looks to me like a cleaner/safer method.
> 

Well I think Michael has a point, I believe these renames are not
critical, so I'm not sure if we should do this.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org