[FFmpeg-devel] IRC shit smearing

[Michael Niedermayer]

On Fri, Jan 15, 2010 at 09:09:58PM -0500, Jason Garrett-Glaser wrote:
> 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.

You know this would make the code very significantly more messy
While the question if its faster or not is not nearly as clear as you
seem to think. Its very possible that this would be slower.
We surely dont gain L1 cache hits, a 16x16 block and all the variables
easily fit in. 
So whats left is keeping things in registers (not with gcc in this world IMHO)
,merging branches
and letting the CPU reorder instructions accross decode and pixel_handling
That said, the loop filter needs cbp, mv, nnz if iam not mistaken so its
still far from as localized as one might think

also our other decoders are similarly split and are quite a bit faster than
the alternatives _when_ our decoders where optimized by someone who invested
a serious effort.
In that sense i think that multithreaded frame decoding would gain us most
and after that i think there are many optimizations that would gain more
speed per messiness than your suggestion above.
But i would be very happy if you could elaborate on why such rearchitecture
would be faster in your oppinon. (it does not seem particularly hard to do
such change, i just dont terribly like it and doubt its speed advantage)


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

I hate IRC, and IRC is a huge waste of time, i prefer to work on the code
and when iam done look at the mailinglist and when iam done again do something
else. IRC is rater randomly timed messages that pulls one attention away from
what one is working on.


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

I have no problem with fun about my code at all, its that its done
"behind my back" that annoys me. If you send me a mail or post it to
a ML that i read thats perfectly fine with me


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

and iam the opposite i prefer the ML over IRC
i see the problem, iam not sure how to solve it

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- 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/20100116/33c69d36/attachment.pgp>