[MPlayer-dev-eng] [PATCH] autoq support for control()

[Juan J. Sierralta P.]

On Mon, 2002-02-11 at 09:56, Michael Niedermayer wrote:

> > 	Had or has ?
> had, i fixed it, anything wrong with it?

	Nope. It's the original C function ? I remember it was AAN.

> > 	The problem of AAN is sometimes his strength, the idea of folding
> > the last multiplications with the quantization can be hard to implement
> > and make things dificult when you have multiple DCT implementations.
> > That's why I said weeks ago that if we could have a common set of
> > IDCT/DCT in C,MMX,XMMX, etc it would be easier and maybe faster to avoid
> > diferent quant matrixes and coef permutation.
> imho its faster with the permutations, its simply because these permutations 
> need nearly no time
> for decoding, there is no extra permutation, the decoder simply puts the 
> coeffs into the correct permutation for the idct, but with a unpermutated 
> idct it still has to do zigzig permutation so there is no speed win here
> for encoding, its not a big deal either as the quantizer knows whch coeff is 
> the last non zero and so only the coeffs up to the last non zero are being 
> permutated

	Ok. I read some comments on mpegvideo.c that the DCT doesn't use the
permutation so we have to permute in C. But the permutation it's on the
TODO.

> 
> > 	BTW. Why SSE couldn't help on DCT/IDCT ? How much time is spent on MMX
> > DCT scaling things ? Because AFAIK one of the advantges of SSE/SSE2 is
> > the SIMD on floats.
> yes but SSE on both the P3 & P4 need 2 cpu cycles to do 1 calculation on 4 
> floats
> and mmx needs 1 cpu cycle to do 1 calculation on 4 16-bit shorts, and at 
> least some part of the dct/idct can be done in 16-bit
> btw. the "more accurate" SSE IDCT could cause problems, because all thouse 
> "shitty" players use integer IDCTs so there could be stripes and green blocks 
> again ...

	Note that I don't put MPlayer on the "shitty" players list ;)
	Another questions, I remember that the guys from libmpeg2 posted some
changes on their IDCT on ffmpeg list after you demonstrated the bias
problem with their IDCT. As somebody tested if this changes fixed the
bias problem ? I believe that having a buggy IDCT by default isn't good
and don't understand why it's used by default.
 
> >
> > > visible on i-frames but the problem dissapeard after a few p-frames
> > > instead of getting worse and the decoder doesnt use te dct so there are
> > > no differences between decoders ...
> >
> > 	Agree on that idea, when I put the first MMX DCT on ffmpeg I take some
> > that weren't accurate and gave me acumulations errors. This is going to
> > an holy war. Just to make clear, let`s review on Arpi's TODO I agree
> > with him that maybe the bitstream writer could be optimized first. Then
> > I think the MB skip could give good results.
> btw what is draw_horiz_band() good for, it looks like its for sliced 
> decoding, why isnt it used?

	No idea, it's there only for h263 and mspeg4 and it's a callback.

-- 
Juanjo sin .sig :(