[MPlayer-dev-eng] Re: [MP] [PATCH] "turbo" mode

[Guillaume POIRIER]

Le mer 15/09/2004 à 20:36, Matthias Wieser a écrit :
> Am Mittwoch, 15. September 2004 16:57 schrieb Guillaume POIRIER:
> 
> > So here's the PSNR comparison on 2nd pass:
> > without turbo:
> > PSNR: Y:42,09, Cb:43,18, Cr:43,06, All:42,41
> >
> > with turbo:
> > PSNR: Y:42,08, Cb:43,16, Cr:43,05, All:42,39
> 
> And "standard mode" without some extremely cpu-hungry options:
> PSNR: Y:42,08, Cb:43,17, Cr:43,05, All:42,40
> at even more fps! 
> 
> 
> OK, I did not run any comparison ;-) but as your patch decreases global 
> PSNR it should be compared to mencoder without turbo mode but with 
> slightly less CPU-hungry options.

That's a really good point you've got here.
First, I'd like to point out that I consider this patch as a "proof of
concept" that it's possible to dramatically decrease encoding time
without noticeably affecting PSNR.
Right now, I do thing too many flags get zapped, I just wanted to see
how far it was possible to go down the road of disabling options.
With my first patch, I wasn't modifying PSNR with "turbo" mode. 

I did another test without "qns", and had an interesting surprise. 
without turbo, 1&2nd pass: 17fps :
PSNR: Y:42,17, Cb:43,16, Cr:43,05, All:42,46
with turbo, 1st pass @ 57fps, 2nd pass @ 16fps:
PSNR: Y:42,17, Cb:43,15, Cr:43,04, All:42,46

(turbo has been disturbed a bit by some other CPU & disk activity)
So here we still have pretty much same PSNR. Looks like qns was
degrading PSNR.... 

> And you should evaluate the PSNR differences between individual frames.

How do I do that? How may that be reverent ? Do you mean that given that
the statistics are not as good, maybe say, first frames lack/have too
much bits?


> It could be possible that mencoder in turbo-mode thinks that some scenes 
> are extremely bitrate demanding but with the options of pass 2 the scene 
> isn't difficult to encode anymore. So your patch might change the 
> distribution of bitrate in a way that leads to only slightly lowered 
> global PSNR but to some really bad looking scenes.

Then, could you tell me what flags really should be left untouched? 

Also, I was thinking that given that first pass' video is re-directed
into /dev/null, we should _always_ run first pass with vqscale=2. That
_might_ reduce the gap between turbo/non-turbo
... or that's what I thought!
If I quantizers' first pass to 2,
without:
PSNR: Y:41,93, Cb:42,93, Cr:42,82, All:42,22
with turbo:
PSNR: Y:41,98, Cb:42,98, Cr:42,87, All:42,27
Well, it doesn't make much sense to me... But I guess it's maybe time
to test "turbo" mode with a longer sample.

Any feedbacks welcome (in particular: which options do need to be
left on)

Regards,

Guillaume