[FFmpeg-devel] [PATCH] Some lavf renames

[Stefano Sabatini]

On date Wednesday 2009-01-21 11:09:45 -0800, Baptiste Coudurier encoded:
> 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.

I agree they're not critical, bbut they don't look like very
problematic, these are the kind of problems which get resolved in few
minutes, while they improve the overall consistency -> readability and
so ease the work of new applications writers.

Regards.
-- 
FFmpeg = Fostering Free Muttering Powered Emblematic Gymnast