[x264-devel] Constant QP with VBV

[Tsahi Gilk]

I don't see how I can get the SSIM from the encoder API.
Can you point me to the API function?

Tsahi.

-----Original Message-----
From: foxyshadis [mailto:foxyshadis at hotmail.com] 
Sent: Monday, February 13, 2012 8:54 AM
To: Mailing list for x264 developers
Cc: Tsahi Gilk
Subject: Re: [x264-devel] Constant QP with VBV

On 2/12/2012 10:35 PM, Tsahi Gilk wrote:
> How can I know the quality of each encoded frame?
> Can I get it from x264 API?
>
> Tsahi.
>
> -----Original Message-----
> From: x264-devel-bounces at videolan.org 
> [mailto:x264-devel-bounces at videolan.org] On Behalf Of Jason 
> Garrett-Glaser
> Sent: Sunday, February 12, 2012 6:38 PM
> To: Mailing list for x264 developers
> Subject: Re: [x264-devel] Constant QP with VBV
>
>> I came across xsplit documation who claims to do with x264 exactly 
>> what I want to do:
> Where in that does it say the word "QP"?  I certainly don't see it.
>
>> I want to encode videos with constant QP and maximum frame size. I 
>> don't care about average bitrate. CRF does not meet the target QP I requested.
> I do not see the purpose of a "target QP" outside of encoder testing.
> --qp is a developer-option only and should never be used for any serious purpose, with the exception of --qp 0 (lossless).  Constant QP is not constant quality and should [almost] never be used.
>
> What Xsplit does, and what is recommended, is --crf + VBV.
>
> Jason
> _______________________________________________
>

If for some reason you just want to try to make this work for giggles, you can easily do it with the C interface, but not the command line. Since that's almost certainly not what you want, I won't bother with writing an example.

If CRF did not work at all, you either aren't using it right, used too high a value, or have unrealistic expectations of the buffer you chose. Get rid of all your command line options and start over with the level/profile and preset only, then go from there. Do not follow any guides about "tweaking" x264 settings, especially not guides from 2006. To find out whether your maxrate/buffer is just plain unrealistic, you can always encode with --crf 1, and if it still looks terrible despite maxing out your buffer that's not crf's fault. Go slower if you can't raise your cieling at all, or preprocess to reduce some complexity.

To obtain the quality of each frame, view it. Quantization has little to do with algorithmic frame quality and nothing to do with perceptual frame quality, which is all that matters. As a reasonable approximation you can obtain the SSIM of each encoded frame from the API after encoding.

foxyshadis