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

[Michael Niedermayer]

Hi

On Monday 11 February 2002 02:16, Juan J. Sierralta P. wrote:
> On Sun, 2002-02-10 at 21:29, Michael Niedermayer wrote:
> > > 	Most AAN implementations aren`t IEEE compliant.
> >
> > i dont care about IEEE ;)
>
> 	Just speed.
no, walkens idct did pass the IEEE test and caused stripes ... 
i care about quality & speed...

>
> > btw what does libmp1e use? i dunno but i would guess that its an AAN dct
> >
> > [...]
> >
> > > > imho if u can see a difference between the c & mmx dct than there is
> > > > a bug somewhere
> > >
> > >  	Not me. The players that have fast IDCT. Like Windows Media Player.
> > > If the DCT is inaccurate then the "inaccurate" IDCT will show artifacts
> > > and users blame the encoder :(
> >
> > hmm, imho its a question between idct differences not dct
> > even if the dct is inaccurate, the encoder will use the accurate idct
> > before storing the data for motion compensation so i cant imagine how
> > this could cause troubble ...
>
> 	Did you see MPEG files generated by ffmpeg on Windows Media, MTV or
> Java Media Studio before your simple idct ? It`s the same problem when
no, but they should show the same stripes...

> we use a bad DCT.
no its not, the dct can be inaccurate, it might increase filesize but there 
will be no accumulated errors
for example the c dct had wrongly permutated scaling factors (that certainly 
caused significantly more differences than the a correct aan dct) and it was 
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 ...

Michael