[FFmpeg-devel] [PATCH] Add libavsequencer.

Sebastian Vater cdgs.basty
Thu Aug 19 01:39:02 CEST 2010


Stefano Sabatini a ?crit :
> On date Wednesday 2010-08-18 18:49:04 -0400, Ronald S. Bultje encoded:
>   
>> Hi,
>>
>> On Wed, Aug 18, 2010 at 6:22 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>     
>>> On Wed, Aug 18, 2010 at 06:04:20PM -0400, Ronald S. Bultje wrote:
>>>       
>>>> On Wed, Aug 18, 2010 at 5:58 PM, Stefano Sabatini
>>>> <stefano.sabatini-lala at poste.it> wrote:
>>>>         
>>>>> So in the end I suggest this course of action: apply the lavseq patch,
>>>>> *or* if we want to add more stuff to it before to commit it, then
>>>>> maybe we should focus on the BSS. Once that's ready, we can create
>>>>> lavseq *and* immediatly commit the BSS definition.
>>>>>           
>>>> I don't want anything committed until I've seen all patches required
>>>> for TCM playback posted to ffmpeg-devel so we can judge whether each
>>>> component is actually necessary.
>>>>         
>>> did you look at this patch?
>>> its just adding a libavseq directory and what is needed in Makefile
>>> configure and some code returning version numbers for the new lib
>>> this seems quite independant of whatever would be done inside
>>> libavseq to me
>>>       
>> Yes. The question is whether we need a versioned libavseq. What public
>> API will be versioned?
>>
>> We already discussed that for the time being, BSS will be private
>> because we'll want to modify it a lot. The synth mixer should not be
>> public, imo. What, then needs a public API with library versioning
>> etc.?
>>     
> [...]
>
> On the other hand having all the code packaged in a single lib may
> help (for example would be simpler to disable all the code and keep it
> disabled), and we could just keep the version to 0.0.0 and tell people
> not to use it (so we won't need to document API changes).
>   

Version 0.0.0 and a @note that this is unstable for each API function
fits this very well, in addition we have it as default disabled. I think
if someone really uses code in that case, it is meant only either for
internal private use or for helping debugging and testing, so I'ld
prefer this.

-- 

Best regards,
                   :-) Basty/CDGS (-:




More information about the ffmpeg-devel mailing list