[FFmpeg-devel] [PATCH] Add libavsequencer.

Sebastian Vater cdgs.basty
Wed Aug 25 13:16:25 CEST 2010


M?ns Rullg?rd a ?crit :
>   
>>>> 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.
>   

Could you clarify here, what you exactly mean? I really don't understand.
Maybe with some examples showing the issue on a strong emphasis and what
you expected and got? Thanks in advance!

>   
>>>> 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.
>   

What's the problem you see here with this approach? After all, this is
quite complex, and small changes can have side effects (sometimes not
easy to track by audible means).

As said, I want to use that as a base of a automatic regression test only.

>> 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.
>   

I just changed the API again, yesterday. There were only smaller
changes, but ...


>> 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?
>   

Some files still change too frequently and too much in a short period,
i.e. sending patches has for some parts a pretty high probability that
once review is done (which can quite a bit of time) the code does not
match the current progress anymore.

I am still thinking of the best way to post the patches actually, i.e.
which parts should it all contain and which not? I got suggested to
remove anything from the patches which is currently unreachable, etc.
Figuring that out, is despite the large structures not always that easy.

>   
>>>> 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.
>   

Yes, solving that with define's as you showed me with the IFF-ILBM
decoder optimization lut's, would be way nicer, for the mixer I strongly
was preferring speed over size.

>   
>>>> 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.
>   

I'll test uploading again today evening. So check out for files, then. ;-)

-- 

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




More information about the ffmpeg-devel mailing list