[FFmpeg-devel] [PATCH] Add libavsequencer.

[Måns Rullgård]

Sebastian Vater <cdgs.basty at googlemail.com> writes:

> M?ns Rullg?rd a ?crit :
>> That list is read by only a few people.  Something as intrusive as
>> this needs a broader review.
>
> Yes, that's true! No panic, we will start with this very soon.

We can't start until you create and post those godforsaken patches
we've been asking for.  MINIMAL patches.

>>>> >From what I saw looking at the tucomposer source earlier, I say it is
>>>> humanly impossible to turn it into ffmpeg-worthy code in the time
>>>> which has been available.  Your attempts at dodging reviews and
>>>> refusal to submit a minimal patch set reinforces this feeling of mine.
>>>>       
>>> Why do you look still at TuComposer's original source?
>>
>> I looked at it a couple of months ago after you posted a link to it.
>> It was total garbage.
>>   
>
> I still want to hear from you, what's the point considering you it being
> garbarge? When I asked you this during that time, you simply complained
> about an unnecessary cast.
>
> I mean, you surely neither compiled nor tested it. I know that the
> coding style I was using during that time, is somewhat weird, the
> backport from 100% Asm doesn't make it any better, probably.

You said it yourself.

>>> Also, some parts already have been reviewed (see ffmpeg-soc mainly for
>>> that), so why you are concerning me, that I'm dodging reviews?
>>
>> A while ago you proposed that, to expedite the process, only a part of
>> a huge blob of code be reviewed, and the remainder accepted on faith.
>> I call that dodging review.
>
> I think you mean the part where we were talking about the mixer stuff.
>
> The point here is that the mixing functions are to 99% very similar,
> i.e. 16-bit mixing in differs in int16_t vs. int8_t for 8-bit mixing and
> shifting. It's a total of 23k lines which is pretty large.
>
> My idea here was, that just 2-3 of these functions are reviewed, then we
> discuss of creating #define macros for these and therefore get rid of
> 20k lines, making the whole stuff much more easilier to maintain and
> also to review, saving us all huge amounts of time.
>
> So you simply misunderstood that part, sorry for this!

I would appreciate if you dropped that belittling attitude.  You speak
as though to a small child who believes he has seen an elf.  Most
people, little children included, take offence at being addressed in
such a manner.

>>> Regarding the minimal patch...this is just what you have in front of
>>> you! A minimal patch, which does simply nothing else than adding the
>>> library...or did you mean sth. else here?
>>
>> That patch does NOTHING useful.  Ronald asked you repeatedly to submit
>> a full set of patches allowing SOMETHING to be done with the simplest
>> file format.  You continue to (rather clumsily) attempt to evade this
>> request.
>
> I already told them that I want to do first a port which has the same
> compatibility as TuComposer regarding playback,

Not in my svn.

> which is quite close now. The point is, once we review it on a
> larger scale here and also the whole stuff, we'll probably do some
> API changes, internal code logic changes.

If API changes are expected, it clearly is not ready for mainline.

> This will require regression tests as well (which I want to write once
> it's on par with TuComposer regarding playback compatibility). From then
> on, we can easily see when some files change playback (regression test
> failures).
>
> That's the reason I want to wait a bit with the patches, hope you
> understand that better.

I understand the words you speak, and I disagree with them.  Get on
with the patches already.  Or don't, fine with me.  You're the one who
wants this committed.  I couldn't care less.

> Anyway, why do you think that I'm against reviewing it? After all, the
> review process makes a) code quality better b) improves readibility
> (documentation and code) and c) fixes bugs. So again, why do you think I
> try to avoid this?

How else should I interpret your refusal to send reviewable patches?

>>> Since all that stuff is large,
>>
>> That is a problem.  You, however, appear to be quite proud of the
>> bloat you have produced.  That is not a good sign.
>>   
>
> Why do you think it being bloat?

An excess of 20k lines for a simple audio mixer is bloat, whichever
way you look at it.

>>> I'll have to submit the IFF-TCM1 test files to some central place,
>>> though.
>>>     
>>
>> That would be a start.
>>   
>
> Could you check what's wrong with anonymous FTP here? Some weeks ago I
> tried to upload some files, could create a directory but not upload
> anything.

FTP is working fine.

-- 
M?ns Rullg?rd
mans at mansr.com