[FFmpeg-devel] [RFC] H.264/SQV3 separation: h264data.h

[Måns Rullgård]

Diego Biurrun wrote:
> On Tue, Dec 16, 2008 at 01:31:32PM +0100, Michael Niedermayer wrote:
>> On Tue, Dec 16, 2008 at 11:01:34AM +0100, Panagiotis Issaris wrote:
>> > On Tue, 2008-12-16 at 02:26 +0100, Michael Niedermayer wrote:
>> > [...]
>> > > > There have been tons of changes to h264.c that were not subjected to
>> > > > the speed inquisition, everything PAFF-related jumps to my mind for
>> > > > example.
>> > >
>> > > benchmarking past changes is welcome, i surely think we should do that
>> > > one day and look into speedlosses.
>> >
>> > Now this isn't not exactly fair, is it? Those benchmarks should have
>> > occurred before the patches got applied. You can't expect people to
>> > accept there patches being rejected for some speed loss, while others
>> > got committed without benchmarking.
>>
>> *if you care why did you not
>>  complain when whatever changes you speak of got commited?
>>  And if you dont care, why do you complain now?
>
> He is complaining about the relative fairness of the treatment.  Other
> changes are not subjected to extensive benchmarking requirements, this
> one is.

This is not a question of fairness.  If patches have been accepted in
the past without benchmarking (pure bugfixes don't count for obvious
reasons), that is unfortunate.  Such oversights in the past must not
be used to justify continued sloppiness.

Quality comes as a result of strictness, not from fairness.

While I do consider Diego's cleanup efforts worthwhile, this particular
patch undoubtedly still has some questions unanswered.  Someone reported
a much greater slowdown than Diego measured, so this must be investigated
until we can find the cause.

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