[FFmpeg-devel] [PATCH] Add libavsequencer.

Vitor Sessak vitor1001
Thu Aug 19 21:00:52 CEST 2010


On 08/19/2010 12:04 AM, Ronald S. Bultje wrote:
> Hi,
>
> 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.
>
> I don't want duplicate code, I don't want overly complicated code and
> I don't want overdesigned code. I want exactly that code necessary for
> TCM playback. Nothing more. Those patches, we will review together,
> removing things that are unneeded/unused, removing code available
> already elsewhere in FFmpeg, and simplifying it to the best of our
> ability. Once that process is done, we can commit the individual
> parts.

I've read the whole thread, and I really think this is a great idea. 
Indeed, let's see a patch (as big as it needs to be, _but not bigger_) 
to make playing TCM files work. That means that _every_ field in _every_ 
structure should be:

(a) written by some code in the patch
(b) read by some code in the patch

Everything that is there for the future, for editors, for visualization 
and for transcoding should be added _later_ (but maybe it is a good idea 
to keep it in your tree). As I said, simpler patches are approved 
faster, so let's make this patch as simple as possible (and the simpler 
way by now is with no new library).

> Committing one part without knowing how the next part uses it is about
> the worst design nightmare possible.

I agree also with this. The right way to review the BSS is seeing where 
and how each field is used.

-Vitor



More information about the ffmpeg-devel mailing list