[FFmpeg-devel] [PATCH] Add libavsequencer.

[Sebastian Vater]

Vitor Sessak a ?crit :
> On 08/19/2010 11:44 PM, Sebastian Vater wrote:
>> Vitor Sessak a ?crit :
>>> On 08/19/2010 10:02 PM, Sebastian Vater wrote:
>>>> Vitor Sessak a ?crit :
>>>>> 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).
>>>>
>>>> To summarize that for the different parts of avseq:
>>>> 1. The BSS:
>>>> All fields are required (since TCM uses them all).
>>>
>>> Not really. There are a lot of "max_xxx" and "min_xxx" that could be
>>> replaced by a constant without changing the player output.
>>
>> Nope these fields are in the IFF-TCM1 file, too. Remember, they're user
>> editable and therefore IFF-TCM1 stores the values, too. Constants won't
>> help here.
>>
>> IFF-TCM1 contains ALL fields which are now in the BSS, except the
>> pointer stuff I moved already to player.h.
>
> They contain this field, but if this field is just ignored and the
> code uses a constant, does playing fail? If the file contain data that
> is not strictly necessary for playing perfectly, this data should be
> ignored by the decoder in this first patch (ignored in the sense that
> it will not store it in any struct).

Yes, playback can change fundamentally if these fields are ignored! This
is rare, but I have some modules which sound really wrong if these
fields aren't utilizied (and no, constant is not enough here). See
AbsDis13.TCM (converted from AbsDis13.MOD) for example.

This mainly affects sample rate limits, but others are also affected,
too. I don't know just out of head, which of my 1000 modules causes
which limit to change output, but all these min/max values are changing
output if utilized! That's why I'm such piecy about keeping them!

In fact, this was the solely reason I invented them after all! Because I
noticed that there's no chance to correctly playback some files without
having such fields set dynamically. Once they were in, I then thought,
well, they're here, so make them user-editable, so you can create e.g.
locked volume / panning instruments and that all nice stuff (just set
min vol == max vol or min pan == max pan).

I think, the misunderstanding we have here is, that you consider them as
some kind of hard limit (as usually the min/max terms suggest), but they
aren't. They're user customizable limits (which though are set from
demuxers / decoders in addition to this if a alien format specifies such
things also).

>
> It make sense, but trying to keep backward and forward compatibility
> while AVSequence is been intensely developed is a nightmare. I'd
> suggest you change the BSS with no regard of how TCM is and afterwards
> worry about saving TCM files (or else you will be stuck with all the
> internal structure of the original TuComposer with no improvement is
> possible). For the moment, it is better just to skip fields that the
> BSS do not contain now (if, obviously, they are not needed for correct
> playback).

That's a very good point, let's finish all that stuff for now and then
integrate that into a new file format (but hey, that's why I spoke of
IFF-TCM1 version 2 and not version 105 ;-)). Of course, we could collect
all changes into one file format change.

>
>> On the other hand, investing just another total new format, should be
>> avoided as much as possible, esp. if we have a format already which does
>> the job quite well. Maybe we could create, though, a mirror of it for
>> little endian CPU's (RIFF-TCM1 or RIFF-AVS1), but well that are topics
>> for the future.
>
> Why? You know you cannot do (portably) things like
>
> struct somestruc *s;
> uint8_t *buf;
> memcpy(buf, &s, sizeof(*s));
> write_buffer_to_file(buf, sizeof(*s));

I wan't to do this, anyway, I just thought of a nicer format for little
endian freaks.

>> b) You (Vitor Sessak) for causing me really brainstorming me during the
>> BSS reviews
>
> Thank you too for keeping your head cool with the feedback, no mater
> if you agreed with it or not.

Which actually sometimes wasn't easy (but won't blame you for that or
sth. else), the main problem here is, that most of the stuff I did
regarding is way 10 years ago in the past and it's just hard to remember
what I did there for what reason, esp. because I was very spare with
documentation. Well lesson learnt again! ;-)

That's also why a lot of points just come back into front from time to
time (like the hardware mixing when the discussion was about the mixers,
it's been such long I was actually dealing with this, I simply forgotten
that over weeks during discussion).

That's also why it's useful to simply start some nostalgia discussion
(as I did with Stefano...and then I suddenly remembered all that again).

Maybe some of you also now understand a bit better, why I often talked
about old Amiga times in IRC chat.

It's not only pure nostalgia in the sense of: "Oh, how well the past
times was *melting*", but it also was there to help me to remember what
I did in these times, and this is really important for TuComposer's
port. It's not really easy to remember each of the 100k lines I wrote 10
years ago without discussing certain parts of this time.

And even still 4 months after part of FFmpeg there's still a lot of
stuff which still has to pop-up in my mind again regarding my code.

Hope this clarifies some more things (esp. to all those why were
wondering why I was so much talking about that)...

-- 

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