[FFmpeg-devel] IRC shit smearing

[Jason Garrett-Glaser]

On Fri, Jan 15, 2010 at 8:46 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> Hi
>
> A reply to a IRC discussion:
>
> <Compn> Dark_Shikari : so now that h264 is split, are you going to speed up
> some functions? :P
> <Compn> hehe
> <mru> slicing a file randomly into a smaller bits and glueing them back
> together with #include isn't exactly what Dark_Shikari had in mind
> <mru> or am I wrong
> <Dark_Shikari> lol
> <Dark_Shikari> he took a fat goose, chopped it up into bits
> <Dark_Shikari> and stitched it back together
> <Dark_Shikari> but it doesn't do much to hide the fact that the old bird is
> dead inside.
>
> ive removed the svq3 #include people didnt like at the begin of the cleanup
> and h264.c is now nicely split into C files that are compiled to seperate
> object files like it should be.
> the nasty h264_mvpred include in h264.h is a quick workaround for a
> compilation failure.
> Considering that, i think you guys are a little overshooting here. We never
> had a problem in the code in any way compareable to what is being raised,
> dark shikaris architectural problem is still waiting for some clarification
> of what that is supposed to be.
> Short of multithreading, a few minor optimizations and a few bugs iam not
> aware of an issue.
> That said, what mru did with the #ifdefs is uhm, not so hot either.
> Also i welcome your guys contributions in terms of code as well as comments
> much more than this kind of shit smearing about my hard work behind my back.
>
> Dark_Shikari & mru If you have suggestions for improvment of what i do
> my email address is in the from line of this email, if not then i dont
> think you have to do this kind of shit smearing.

I completely agree with the split; it was much needed.  I'm just
saying that it isn't sufficient to do what Compn asked for (a very
significant speed boost by rewriting stuff).

The architectural change needed is that entropy decoding and idct need
to be re-coupled.  Currently, we do this:

Cache loading:
[load intra pred modes for neighbors]
[load MVs for neighbors]
[load nnz for neighbors]

Entropy decoding:
[decode MVs/modes]
[decode CBP]
[decode DCT coefficients]
...
Pixel stuff:
[motion compensation with MVs]
[intra prediction with modes]
[iDCT with DCT coefficients]

How it should be:

[load MVs for neighbors]
[decode MV]
[motion compensation]
[load nnz for neighbors]
[decode CBP]
[decode DCT coefficients for block 0]
[iDCT for block 0]
[decode DCT coefficients for block 1]
[iDCT for block 1]

And so forth.  This of course requires templating for CAVLC vs CABAC.

> ahh and everyone who now thinks "how did this leak to michael, how can we
> prevent this from happening again"
> Think for a moment why exactly you are trying to prevent the maintainer
> to hear about critique about his code on a IRC channel related to the project
> tgat contains his code? Who is this helping?
> Surely not ffmpegs quality
> are you so much a coward to not be able to tell your critique to me?
> or do you want the problems you flame about to stay there? because if
> you succeed in keeping the critique hidden from me chance are the problems
> wont be known or corrected or you might plain belive theres a problem where
> there is none.

"Leak"?  It's on a public IRC channel.  I *EXPECT* you to be there.
The fact that you are not there is a problem, not the reverse.  There
is nothing wrong with having fun making fun of each others' code from
time to time.  And yes, that means making fun of problems we don't
intend to fix.

> The reason why theres no dts returned is thats it isnt needed
> Or if you think iam wrong you could somewhere on some place behind my back
> say why the dts is needed. Just dont tell me directly as i might fix the
> issue and you then had one less to complain about behind my back.

It's only "behind your back" because you refuse to be participate
there.  There is absolutely no intention of "hiding" anything from
you: I just prefer to discuss things in a realtime environment as
opposed to a mailing list.

Dark Shikari