[XviD-devel] Quality optimization

[Christoph Lampert]

On Thu, 23 Jan 2003, Radek Czyz wrote:
> My experiments show that during halfpel refinement, the biggest
> slowdown comes not from the speed of comparsion function, but from
> memory access. I guess that means that we an use a more complicated
> function (maybe even dct) while still having the same speed.

Then we have to speed up memory access by either not doing interpolation
in huge full frames (3 or 4 of them are needed), or by adding better 
prefetch. We're not doing streaming dot product, we know in advance 
what memory locations we'll most likely need for the next block. 
 
> > d) Set B-frames only when helpful
> >
> > A clip can benefit very much from Bframes, or the results can be horrible.
> > In one of the VQEG test clips, I had a PSNR drop from 46.05 to 41.40
> > (-4.95db) just because of activating 1 bframe! Average(!) quantizers
> > jumped from 2.26 to 5.22. But there is also a clip where PSNR was
> > increased from 34.3 to 35.5 (+1.2dB). XVID already has a dynamic test for
> > this, but it's a very simple check...
> >
> > Proposal #4: Implement a better criterion for dynamic bframes.
> > (first we have to find one, but if necessary, just use brute force)
> 
> Do you have any idea how brute force should work? The goal is to have
> future frame, with it's vectors, ready before the decision. But if
> it's ready, than the decision has been already done.... That doesn't
> make sense.

Use a low max_bframes number, like 2 or 3. 
Encode as PPP (most basic settings, only fullpel etc), encode as BBP in
saving the result in two different buffer. Decide in some why  (quality
vs. sizes) which is better, use that. 


> Of course I'd also would like to see a better decison.
> 
> > I'm not sure if the benefits of b-frames can be measured by simple PSNR
> > comparisons: Of course the PSNR of bframes is generally lower than if we had
> > coded a pframe instead (simply because bframe quant is higher), however
> > bframes' lower quality don't influence the remaining picture sequence
> > (because bframes are not used as reference). If we now assume normal viewing
> > conditions (a video played back at ~25 fps), the quality decrease when a
> > bframe is presented for only a short time (1/25s) might not be noticed at
> > all.
> 
> I agree, but with slightly different arguments ;) . B-frames might
> have horrible PSNR but still look very good. The picture, when
> compared pixel-by-pixel, might be different than the original, but
> it's still sharp, because both references are sharp, and is not
> blocky, because SAD wouldn't allow visible blocks (that's the way SAD
> is). As a result, b-frames don't look bad even when someone would look
> at a still picture, and at the same time original might look very
> different - especially the noise is very different.
> 
> > Btw. in later tests I noticed, that ffmpeg's overall quality with Bframes
> > get much better when vhq is enabled in ffmpeg, so their mode decision in
> > bframes might simply be very bad. Still, its a fact that sometimes
> > bframes are beneficial and sometimes they are not, and I really have to
> > adapt the test-script to XVID.
> 
> Do they use vhq for mode decision in b-frames? I'd be a bit worried
> about it. As b-frames have higher quant and good motion compensation,
> they usually have no DCT data at all. Therefore, vhq mode decision
> would simply add bits needed to code the mode (1..4) and bits needed
> to code vector. Direct mode would always win...

If a compensated block has no DCT data, then direct mode SHOULD always
win... since it needs the fewest bits. Something like that? Yes, it
might be a little slow, I know. 


gruel