[FFmpeg-devel] IRC shit smearing

[Jason Garrett-Glaser]

> i didnt do it that way for h263/*mpeg4 and i still beated them all at
> least back then. Of course h263 was simpler and i spend alot more time
> on it. That said iam of course very interrested in what ideas we can
> borrow from CoreAVC i just dont like the argument "its better because
> CoreAVC does it" based on that we would have to remove some optimizations
> if we have tricks CoreAVC does not.
>
> Also if you could make a todo / to-try list of what could be optimized
> i know you posted one mail and i still have that, as well as this
> mail but i think it would be more ideal if this all was in one
> place to which people could add (that is roundup or just commit a
> list tp h264.c or a h264todo.txt)

It's a hard question.  The thing that makes this hardest is that I
can't just look at libavcodec and CoreAVC and say "CoreAVC has this
cool trick, libavcodec doesn't".  So, since I can't easily port
massive structural changes to h264.c merely to bench them, it's hard
for me to say for sure exactly what makes it so much faster.  I can
say some things that *aren't* what makes it so much faster, but that
doesn't help us too much; all my speculation ends up being of the form
"CoreAVC is structured in fashion X, libavcodec is not, maybe X makes
it faster".

I would of course like to simply be able to say "do X, and we're sure
to get a lot faster".  But of course I can't, and it's really
aggravating to me, in large part because a lot of things CoreAVC does
differently are *not* particularly good ideas in my mind.

Dark Shikari