I would like to be able to do something like:
(quantizer to the minimum -> q=2.2 unless bitrate > maxrate)
or
(quantizer to the minimum -> q=2.3 unless bitrate > maxrate)

So I can vary the final size, but keep quality constant, this way I could fit in some media, for instance.

Why not decreasing average/maximum bitrate? :?

Seems to me that it would achieve your purpose.
Don't forget that although a quantizer is a measure of compression, it doesn't garantee that it will be able to compress the same in all frames.

The size difference in percentage between a simple and a complex image when compressed with quantizer=2 or quantizer=3 is not necessarily the same IMHO.

A bitrate difference is a much better garantee.

EDIT: This is probably a very old formula for a prediction-man like you... ;)

(CD size (MB) * 1024 (KB) * 8 (Kb) ) / movie time (sec) = avg bitrate


Bilu

If I changed the max bitrate, I would make low detail/motion scenes look good, while high motion/detail scenes would look bad. This is not what I want. I want to lower the quality a bit in all scenes in order to fit some media. Yes, I know rising the quantisizer won't change the bitrate needed in each scene in the same way, but in theory, they'll have the same "degree of distortion" (if there's such a word).
About the final size, I can use my CCE prediction method, with a accuracy of 3%, and go much faster than 2pass. :D

One thing I know now: a rate-control equation that ignores texture complexity and avg bitrate = max bitrate seems like a good quality combo.

How about lowering the vrc_eq value, but still using a number instead of a function? It's fractional (between 0 and 1) and doesn't care about texture complexity, making the quality decrease constant IMHO.

Can you test it?

Bilu

Guys,
You're not posting anymore :) : you're chating in public :D
I'm sorry but we, mere mortals, can't keep up with your level of conversation.
Anyway, something you could spare us to play with?
Maybe you favorite command line until now and some tips of what it's supposed to do?
Thanks guys.
Oh and, by all means, keep up the conversation :D
Cheers

@rds_correa
I am at work now, when I come home I'll post my latest command-line. :D

@bilu
Yes, of course. You're telling the encoder: you can't go over max_bitrate, otherwise, use at your own will! :D But note, this don't lead to optimal use of bitrate, this is near CBR for a very "bitrate-consuming" video material... :(
I tried that. If you use 0, filesize really get smaller (about the half). But any other value seems to make little difference in final filesize. Tried 0.1, 0.001, 0.05, about the same thing.
I am starting to believe there's something wrong with our approach. I just checked a 1-pass VBR CCE encode with bitrate viewer, and the quantization curve seems to vary a lot and stay beyond 5 all the time. Maybe this pursue of the straight Q line is not the best quality option. :?:

Can you try 0, 0.25, 0.50, 0.75 and 1, and tells us about the bitrate distribuition differences ? Please... ;)

Bilu

I'll try. But I think I did try 0.5 and made no difference... I did a test with 2 pass VBR, and I saw the same pattern I've seen before with CCE: the bitrate curve seems to follow the quantisizer curve... Interesting.

That's what 2-pass VBR is all about, I think :)

Simple scenes get higher quantizer to lower their bitrates.
The bits spared will be spent on lower quantizers / higher bitrates on more complex scenes.

Of course this is not 100% true: you can have high quantizers and high bitrates together on a complex scene. But on most movies the complexity on spatial detail doesn't vary that much. Most variations are temporal: stalled, slow motion, high motion.

And it's pretty normal that increasing temporal complexity increases the bitrate: after all, there's much more motion vectors and differences between frames to encode. And temporal complexity is harder to compress, hence the lower quantizers :)


Conclusion: temporal complexity (not spatial) makes the bitrate curve follow the Q curve. And temporal complexity is what video (not image) encoding is all about :)

EDIT: Did you made that test with vqcomp=0 ?

Bilu

How about the quality? And the quantizers?


Check this out:

vqblur=<0.0-1.0>
quantizer blur (pass1) Larger values will average the quantizer more over time (slower change).
0.0 qblur disabled
0.5 (default)
1.0 average the quantizer over all previous frames

Now here is a nice reason for vqcomp=1 not working on that fast action scene of VM's test ! :twisted:
A true VBR killer! :twisted:

Please test again with vqcomp=1 (or vrc_eq=tex) and vqblur=0.
And vqcomp=0 (or vrc_eq=1) with vqblur=0 would also be an interesting test... :)

(I think vqcomp=0 will provide better results - because of perceived frame complexity, dark scenes,etc. . Please use vbitrate=vrc_maxrate in both tests)

Bilu

Bilu,

In that case, quality got really bad.

Sorry but I really feel that there's no reason to keep testing this if we can't vary the minimmum quantisizer in a better way. Maybe only a source Mod can fix this... :(

HiBitrate VBR: that's how far as 1-pass encoding goes.

vrc_maxrate=vbitrate
vrc_eq=tex
vqblur=0

This is similar to a XVID method used by some guys for capturing: let bitrate flow freely and avoid any quantizer delays (vqblur-like). And unlike vqscale=2, you know this method respects the max bitrate boundaries.

Quality decreasing would have to be made by:
- processing the input through resizing/blurring/denoising;
- raise min quantizers;

Quality increasing can still be made by:
-adding noise;
- trell,cbp,mbd=2,mv0;


But for most cases we'll want to go 2-pass. Bits are distribuited and when you need to fit in a smaller media the quantizer raising gets distribuited also.

So let's focus now on 2-pass behaviour. SATD is much slower/better than SAD motion estimation but a SAD 2-pass would still be better (and maybe even faster :) ) than a 1-pass SATD.

And of course, avoid vqscale in 2-pass encodings too.


Bilu

1) We should avoid breaking compatibility. That would mean forking Mencoder and having trouble updating our version everytime a bug in the official one gets fixed. We may not have that much man power around :roll:

2) Same result can be achieve through denoising/blurring/resizing.

3) Is quantizer 3 so much different from quantizer 2 in MPEG-2 that you would need fractional quantizers???

4) Ever wondered if fractional quantizers would break MPEG-2 compatilibity?


Bilu

The HiBitrate VBR method should be really useful for converting MPEG-2 streams from Sony MicroMV cameras (MPEG-2 CBR 12Mbps) to DVD format (9.8 Mbps) :!:

(don't know if those cameras still have the audio desync problem)

Probably this method also works as good in both FFMPEG and FFVFW.

Bilu

I wonder how would requantizing (when difference to desired filesize is less than 10%) work with a HiBitrate VBR stream.

Would it worth instead of 2-pass? :roll:


Bilu

Yes.. specially now that my mencoder compiles are giving "core dumps"... :(
Yes, but that would slow down and filter the picure...
Yes...
No, because the generated file has fractional quantisizers in many points (check with BitRate Viewer)
I was thinking about that... No fractional min quantisizer, no fun with 1-pass. :D

To use 2-pass, it's better to feed mencoder AVI/VOB straight, with no avs, because it goes much faster. So I am playing with the internal filters to find a good filter combination for DivX stuff. I also would have to find the optimal combination of settings for mencoder (I'll re-read all your previous posts... :D )
Also about 2-pass, russianexpat suggested in other thread that it's better to use vqscale=1 in the first pass for more accurate results. I'll try that. :D

Just for curiosity, could you try HiBit VBR 1-pass on that action scene you mentioned before? Just to see the effect of vqblur=0 :)

And I think HiBit VBR 1-pass + Noise would also be great in dark scenes.


About vqscale=1:

I think it would be better to do the first pass with vqscale=2.

Bilu

Ok, I'll try vqblur. Actually I meant vqscale=2, but got confused when typing... :D

More and more we seem to benefit from the MPEG-4 experience :)

This was the only difference I found so far, as exposed by Incredible:

http://www.kvcd.net/forum/viewtopic.php?p=61337#61337

MPEG-4 uses much more keyframes (I frames) than MPEG-2, so MPEG-2 has to preserve better the inter frames (P and B frames), hence using lower quantizers on them.

Well, in practice we find two difference: no longer have a need to deinterlace ;)

The HiBit VBR encoding and using qscale=2 on the first pass of a 2-pass encoding is exactly what is used with Xvid nowadays. And works here too :)

With libavcodec-based encoders there is still another advantage: just change the codec parameter, no need to mess with the rest in most cases :D


Bilu