Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question]: can we calculate the QP (Quantization Parameter) from a given bitrate? #503

Open
Ryu0833 opened this issue Sep 14, 2024 · 5 comments
Labels

Comments

@Ryu0833
Copy link

Ryu0833 commented Sep 14, 2024

Hello,
I have been testing the value of "AMF_VIDEO_ENCODER_MIN_QP," and it helps maintain the quality and the bitrate. For example, a MinQP value of 23 gives the best quality with the best bitrate for streaming 1080p60 8000kps avc. My question is, is there a formula or can we calculate the QP (Quantization Parameter) from a given bitrate?

@Ryu0833 Ryu0833 changed the title [Question]: <Is X intended for Y?> [Question]: we calculate the QP (Quantization Parameter) from a given bitrate? Sep 14, 2024
@Ryu0833 Ryu0833 changed the title [Question]: we calculate the QP (Quantization Parameter) from a given bitrate? [Question]: can we calculate the QP (Quantization Parameter) from a given bitrate? Sep 14, 2024
@DimkaTsv
Copy link

DimkaTsv commented Sep 16, 2024

No, i don't think it is possible without encoding source once. Same as you won't be able to blindly predict CQP output bitrate, or target bitrate output quality, as they can vary A LOT depending on source material. Moreover, target bitrate and QP are already two opposite ways of rate control.
Second issue is that even if it would've been possible, automatic calculation of MinQP value would've been counterproductive, as it's efficiency depends on subjective opinion of the user.

Another thing is that Min QP and Max QP by default override your target bitrate, when set QP limit is hit. (If they aren't being hit, they have no impact). Depends on encoded source, you may either waste bitrate or waste quality. In your case you sacrifice quality to potentially improve harder to encode scenes.

MinQP 23 only says "Do at least QP 23 level of compression". Meaning your output quality will NEVER be of a higher quality than CQP23, only lower. Even if it will produce 500 kbps stream, when encoder could've spared 1000 or 2000. [Or 5000 kbps when it could've done 8000].

MaxQP X also just says "Never compress more than QP X". Which will result in your bitrate going way past your target if scene is demanding, as it will compress it at level of CQP X instead.

So in your setup bitrate is limited by QP 23 at lower end, and 8000 kbps at higher end. With some sources bitrate will never hit 8000 kbps. And with others it will never hit QP23 limit. It still technically can somewhat act as constraint so encoder can spare slightly more bitrate on even more demanding scenes. So idea is... Interesting, but i don't think you can just automate it.

@MikhailAMD
Copy link
Collaborator

Yes, this is good description from DimkaTsv

@Ryu0833
Copy link
Author

Ryu0833 commented Sep 16, 2024

hello thank you for the response and your explanation @DimkaTsv

No, i don't think it is possible without encoding source once. Same as you won't be able to blindly predict CQP output bitrate, or target bitrate output quality, as they can vary A LOT depending on source material. Moreover, target bitrate and QP are already two opposite ways of rate control. Second issue is that even if it would've been possible, automatic calculation of MinQP value would've been counterproductive, as it's efficiency depends on subjective opinion of the user.

Another thing is that Min QP and Max QP by default override your target bitrate, when set QP limit is hit. (If they aren't being hit, they have no impact). Depends on encoded source, you may either waste bitrate or waste quality. In your case you sacrifice quality to potentially improve harder to encode scenes.

for my test i did the bitrate stay the same even when the minQP=51 well be high compression bitrate and bad quality but the bitrate stay 8000kps. using fillerdate=true

MinQP 23 only says "Do at least QP 23 level of compression". Meaning your output quality will NEVER be of a higher quality than CQP23, only lower. Even if it will produce 500 kbps stream, when encoder could've spared 1000 or 2000. [Or 5000 kbps when it could've done 8000].

the encoder minQP=0 it well made the encoder try to not compress the scene exmple in switch secen from black scene to a colorfull scene or motion secen. and it noticbale more when use rc=CBR with fillerdate=true. the video bitrate go above the TargetBitrate. and video change in in qualty instant ,not the best expersion for the watchers.

MaxQP X also just says "Never compress more than QP X". Which will result in your bitrate going way past your target if scene is demanding, as it will compress it at level of CQP X instead.

the maxQP=51 it good it help the encoder to compress the frame in any scenes.

So in your setup bitrate is limited by QP 23 at lower end, and 8000 kbps at higher end. With some sources bitrate will never hit 8000 kbps. And with others it will never hit QP23 limit. It still technically can somewhat act as constraint so encoder can spare slightly more bitrate on even more demanding scenes. So idea is... Interesting, but i don't think you can just automate it.

the idea is there a way to instruct the encoder to use a quantization parameter (QP) of variable value higher then 0 when operating under CBR conditions? In situations where the bitrate is limited, such as streaming, having a QP of 0 may not be necessary. However, under VBR conditions, using QP=0 is beneficial because the bitrate can fluctuate.
thx for your time and sorry for my english.

@DimkaTsv
Copy link

DimkaTsv commented Sep 16, 2024

for my test i did the bitrate stay the same even when the minQP=51 well be high compression bitrate and bad quality but the bitrate stay 8000kps. using fillerdate=true

Now... Were you surprised by it? By doing this you quite literally had set encode to waste both quality and bitrate. Because you used CBR (i assumed) AND forced filler data at the same time (which probably may have not been necessary), reducing potential benefits to 0.
Because you force encoder to fill any reduction of bitrate until it hits 8000 kbps. And that's empty data, literal filler.

the encoder minQP=0 it well made the encoder try to not compress the scene exmple in switch secen from black scene to a colorfull scene or motion secen. and it noticbale more when use rc=CBR with fillerdate=true. the video bitrate go above the TargetBitrate. and video change in in qualty instant ,not the best expersion for the watchers.

Because real time encode works based on GOP. Default GOP is... Wait, what was it for capture again? 60? 120? Aka it will insert IDR frame every 1 or 2 seconds. Until it hits IDR frame, it encodes video relative to previous IDR. And on rapid transition you will hit issues. Until you reach next IDR. Your trick only allows to dampen transition by creating slight cushion. If you have anything more demanding than CQP 23 ==> 8000 kbps, you will hardly get any benefit as every frame will require to be of higher compression level just to make encoder fit into 8000 kbps restriction.
Meaning, while your setup is working, it can be counted as "finetuned" for your specific usecase. Change usecase --> change tuning.

You may try use preanalysis and scene change detection to try catching transition and inserting IDR frames. But i am not sure that it will work that well for streaming. And preanalysis is sure as heck takes A LOT of resources from encoder.

the maxQP=51 it good it help the encoder to compress the frame in any scenes.
MaxQP = 51 is default for AVC and HEVC (for AV1 default is 255). For some encoders HEVC10 will have up to QP 63 level.
Setting it manually to 51 won't change anything.
Frankly speaking, even if you set it to, let's say 45, you will hardly notice difference, unless scene is extremely complex. But if you set it to 36 or lower, you may very well notice it as you will go above your target bitrate.

the idea is there a way to instruct the encoder to use a quantization parameter (QP) of variable value higher then 0 when operating under CBR conditions? In situations where the bitrate is limited, such as streaming, having a QP of 0 may not be necessary. However, under VBR conditions, using QP=0 is beneficial because the bitrate can fluctuate.
thx for your time and sorry for my english.

  1. Even if you find a way to somehow find a value that you will need to restrict your encoder with period of refresh, just to apply it, you will need to reinitialize encoder. At least based on my current level of understanding.
  2. In real life situations, encoder will not use QP 0. It will cause too high of a fluctuation, and, frankly, kinda inefficient. There may be reason to restrict maxQP for IDR frames to, let's say 24 or 18 and leave maxQP for P:B frames at defaults. This will kinda force encoder to do higher quality keyframes which are sparse, but then slight reduction of quality of P:B frames trying to fit it under target bitrate will often still provide higher quality for few dozens frames after IDR frame compared to normal encode. But more consitent QP provides less variation and more headroom instead.
  3. minQP=0 maxQP=51/63/255 are defaults. It isn't beneficial. It is how it works under the hood if you don't pass anything.

@Ryu0833
Copy link
Author

Ryu0833 commented Sep 16, 2024

@DimkaTsv You indeed helped with your explanation of the minQP and maxQP, and you helped me understand them. I'm just trying to figure out the best settings for the AMF encoder in streaming. I see that it has the potential to provide a good streaming experience without using pre-analysis.
thank you and have good day

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants