[FFmpeg-devel] [PATCH] Add libavsequencer.
Wed Aug 25 12:34:35 CEST 2010
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
> 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
> 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,
>> 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
FTP is working fine.
mans at mansr.com
More information about the ffmpeg-devel