Mercurial > mplayer.hg
comparison DOCS/tech/encoding-tips.txt @ 15015:23237af42335
Technical explanation of how to use vqcomp, and why, featured by Loren Merritt
on the ML: http://mplayerhq.hu/pipermail/mplayer-cvslog/2005-March/021202.html
author | gpoirier |
---|---|
date | Mon, 28 Mar 2005 16:24:01 +0000 |
parents | 53cd01eabc3e |
children | 4183c4585f1d |
comparison
equal
deleted
inserted
replaced
15014:d82b3dd4e5fb | 15015:23237af42335 |
---|---|
643 why ;) | 643 why ;) |
644 | 644 |
645 A = Rémi | 645 A = Rémi |
646 | 646 |
647 | 647 |
648 ================================================================================ | |
649 | |
650 | |
651 TIPS FOR TWEAKING RATECONTROL | |
652 | |
653 (For the purpose of this explanation, consider "2nd pass" to be any beyond | |
654 the 1st. The algorithm is run only on P-frames; I- and B-frames use QPs | |
655 based on the adjacent P. While x264's 2pass ratecontrol is based on lavc's, | |
656 it has diverged somewhat and not all of this is valid for x264.) | |
657 | |
658 Consider the default ratecontrol equation in lavc: "tex^qComp". | |
659 At the beginning of the 2nd pass, rc_eq is evaluated for each frame, and | |
660 the result is the number of bits allocated to that frame (multiplied by | |
661 some constant as needed to match the total requested bitrate). | |
662 | |
663 "tex" is the complexity of a frame, i.e. the estimated number of bits it | |
664 would take to encode at a given quantizer. (If the 1st pass was CQP and | |
665 not turbo, then we know tex exactly. Otherwise it is calculated by | |
666 multiplying the 1st pass's bits by the QP of that frame. But that's not | |
667 why CQP is potentially good; more on that later.) | |
668 "qComp" is just a constant. It has no effect outside the rc_eq, and is | |
669 directly set by the vqcomp parameter. | |
670 | |
671 If vqcomp=1, then rc_eq=tex^1=tex, so 2pass allocates to each frame the | |
672 number of bits needed to encode them all at the same QP. | |
673 If vqcomp=0, then rc_eq=tex^0=1, so 2pass allocates the same number of | |
674 bits to each frame, i.e. CBR. (Actually, this is worse than 1pass CBR in | |
675 terms of quality; CBR can vary within its allowed buffer size, while | |
676 vqcomp=0 tries to make each frame exactly the same size.) | |
677 If vqcomp=0.5, then rc_eq=sqrt(tex), so the allocation is somewhere | |
678 between CBR and CQP. High complexity frames get somewhat lower quality | |
679 than low complexity, but still more bits. | |
680 | |
681 While the actual selection of a good value of vqcomp is experimental, the | |
682 following underlying factors determine the result: | |
683 Arguing towards CQP: You want the movie to be somewhere approaching | |
684 constant quality; oscillating quality is even more annoying than constant | |
685 low quality. (However, constant quality does not mean constant PSNR nor | |
686 constant QP. Details are less noticeable in high-motion scenes, so you can | |
687 get away with somewhat higher QP in high-complexity frames for the same | |
688 perceived quality.) | |
689 Arguing towards CBR: You get more quality per bit if you spend those bits | |
690 in frames where motion compensation works well (which tends to be | |
691 correlated with "tex"): A given artifact may stick around several seconds | |
692 in a low-motion scene, and you only have to fix it in one frame to improve | |
693 the quality of the whole sequence. | |
694 | |
695 Now for why the 1st pass ratecontrol method matters: | |
696 The number of bits at constant quant is as good a measure of complexity as | |
697 any other simple formula for the purpose of allocating bits. But it's not | |
698 perfect for predicting which QP will produce the desired number of bits. | |
699 Bits are approximately inversely proportional to QP, but the exact scaling | |
700 is non-linear, and depends on the amount of detail/noise, the complexity of | |
701 motion, the quality of previous frames, and other stuff not measured by the | |
702 ratecontrol. So it predicts best when the QP used for a given frame in the | |
703 2nd pass is close to the QP used in the 1st pass. When the prediction is | |
704 wrong, lavc needs to distribute the surplus or deficit of bits among future | |
705 frames, which means that they too deviate from the planned distribution. | |
706 Obviously, with vqcomp=1 you can get the 1st pass QPs very close by using | |
707 CQP, and with vqcomp=0 a CBR 1st pass is very close. But with vqcomp=0.5 | |
708 it's more ambiguous. The accepted wisdom is that CBR is better for | |
709 vqcomp=0.5, mostly because you then don't have to guess a QP in advance. | |
710 But with vqcomp=0.6 or 0.7, the 2nd pass QPs vary less, so a CQP 1st pass | |
711 (with the right QP) will be a better predictor than CBR. | |
712 | |
713 To make it more confusing, 1pass CBR uses the same rc_eq with a different | |
714 meaning. In CBR, we don't have a real encode to estimate from, so "tex" is | |
715 calculated from the full-pixel precision motion-compensation residual. | |
716 While the number of bits allocated to a given frame is decided by the rc_eq | |
717 just like in 2nd pass, the target bitrate is constant (instead of being the | |
718 sum of per-frame rc_eq values). So the scaling factor (which is constant in | |
719 2nd pass) now varies in order to keep the local average bitrate near the | |
720 CBR target. So vqcomp does affect CBR, though it only determines the local | |
721 allocation of bits, not the long-term allocation. | |
722 | |
723 --Loren Merritt |