[MPlayer-dev-eng] Re: Re: PATCH [0/12] CoreAVCDecoder support

[Michael Niedermayer]

Hi

On Mon, Feb 19, 2007 at 11:53:12PM -0500, Compn wrote:
> On Tue, 20 Feb 2007 02:24:16 +0100, 
> Michael Niedermayer <michaelni at gmx.at> scribed:
> 
> > Hi
> > 
> > On Mon, Feb 19, 2007 at 12:19:42PM +0100, Dominik 'Rathann'
> > Mierzejewski wrote:
> > > On Sunday, 18 February 2007 at 14:17, Michael Niedermayer wrote:
> > > > Hi
> > > > 
> > > > On Sat, Feb 17, 2007 at 10:27:42PM -0700, Loren Merritt wrote:
> > > > > On Sat, 17 Feb 2007, Rich Felker wrote:
> > > > > >On Sun, Feb 18, 2007 at 01:42:02AM +0100, Michael Niedermayer
> > > > > >wrote:
> > > > > >
> > > > > >>this wont happen and it shouldnt, its the compilers job, this
> > > > > >>is not 2 pages of code its more like 200 pages of c code ...
> > > > > >
> > > > > >bleh.. :(
> > > > > >is there any sane way to isolate the parts that are actually
> > > > > >the most performance-intensive and only write them in asm? or
> > > > > >is h264 just THAT idiotic that it has 200 pages of
> > > > > >performance-intensive code do to massive overcomplexity?
> > > > > 
> > > > > If we define "performance-intensive" to be anything that runs 
> > > > > per-macroblock, then that makes up 5488 of the 8653 lines in
> > > > > h264.c (not counting anything in dsputil since that has already
> > > > > been asmed). Of course not all of that is used on every video,
> > > > > e.g. a bunch of code is separate for cabac and cavlc. But all
> > > > > of it needs to be considered for optimization if we want all
> > > > > videos to be faster. It can't be narrowed too much farther,
> > > > > since a significant fraction of the cpu-time is spent in code
> > > > > that runs only once per macroblock.
> > > > 
> > > > so my 200 page guess is pretty close 200*25=5000
> > > > 
> > > > 5000 lines of code is a pretty large amount no matter if its to
> > > > be asm optimized or some more highlevel optimizations, maybe we
> > > > could do some contest where the winner gets a real 10l cola (and
> > > > all the fame of being the best) so
> > > > 
> > > > the winner could be selected by simply benchmarking
> > > > there could be 2 classes (P4 and athlon maybe so 2 winners)
> > > 
> > > Maybe include AMD64 (in 64bit mode) as a third class here?
> > 
> > ok, so assuming the relative lack of comments means everyone is so
> > enthusiastic they are speechless lets see what needs to be done
> 
> 
> i have an idea...
> 
> email corecodec people and ask how they do it so fast :)

that would be a waste of time, as its not in their interrest to provide
any information to "competitors" and its likely they dont know it anyway
they might be able to say something but unless they carefully profiled
and compared both their code and ours i wouldnt give what they think too
much weight, also even knowing where the problem lies doesnt make it
dissapear, i can tell you a few things i know could be improved in ffh264,
will you find me someone changing them?
noone works on ffh264 except me and loren, THAT is 95% of the problem

additionally id like to improve ff-h264 and not try to be better then
a random propriatary implementation, that is if we reach their speed theres
no reason not to optimize our code further, i think its a serious misstake
to be too fixed on coreavc, we should rather look at ffh264! also its
not as if coreavc design which we dont know would be the ideal goal or
something, this too could be a very serious misstake

again the goal is to make ffh264 faster not figure out what coreavc does and
copy that blindly

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070220/93e53450/attachment.pgp>