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

[Michael Niedermayer]

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?

*Code has to work before one should optimize it, i think one hardly can
 claim our h264 decoder was working when it decoded just a small fraction
 of h264 streams correctly


> 
> 
> Besides that, in my opinion you can't benchmark code on one particular
> machine and expect a 0.5% performance loss to say anything about the
> codes performance on other machines (other then that the code hasn't
> introduced a substantial performance change on similar machines).

What evidence is there to support this claim?
if i remove some unneeded code and that results in a 0.5% gain on one machine
chances are it also does on most others, its not as if the removial of
code will likely make it slower.


Besides, instead of telling me that i should accept some patch that has
not fully understood sideeffects. Dont you think it would be more
productive if you did work on some code, be that this patch or another?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081216/feeba9dc/attachment.pgp>