[MPlayer-dev-eng] [PATCH] autoq support for control()
Juan J. Sierralta P.
juanjo at atmlab.utfsm.cl
Mon Feb 11 01:17:24 CET 2002
On Sun, 2002-02-10 at 19:56, D Richard Felker III wrote:
> perhaps libavcodec could be modified to use template-style functions,
> included once per mpeg variant, with #ifdefs insteads of ifs. this is
> rather ugly imho, but it may be better than being slow (as it is now)
> or having multiple copies of all the code.
Slow ? Looks like I`m missing (put super great encoder here).
AFAIK libavcodec is one of the fastest encoders that uses ME/MC.
> > > as Juanjo alerady did with MC slices, we could do the same to quant/DCT,
> > > i mean doing DCT for whole slice/frame first, and then doing quantization.
> > are u sure this will be faster?
> > 512 pixels width
> > slice height of 16
> > [16*512 (luma) + 8*256*2 (chroma)]*sizeof(short) = 24kb
> > and the p3 has 16kb L1 data cache
> > the p4 has 8kb L1 data cache ...
>
> the idea isn't that the whole slice fit in the cache -- although iirc
> with an amd rather than those crappy p3s and p4s, it would :) -- the
> idea is to keep both the dct and quant steps from repeatedly ruining
> cache coherency for one another. i've done optimizations like this
> before -- separating complicated operations into several smaller
> steps, even when it may require more intermediate data -- and it's
> improved performance in my experience.
I got your idea. Maybe the word isn`t cache coherency but we
understand. Indeed when I separated the MC on it`s own loop and added
many arrays to store MVs and MB types the impact was despicable. And we
need to separate that in order to allow better bit rate control. And
also storing the MV values in a table will help to some future
transcoding feature.
--
Juanjo sin .sig :(
More information about the MPlayer-dev-eng
mailing list