The H.264 rate controller does generate a bit stream at 50kbps, but does not handle I-frames very well. Any I-frame, whether triggered externally or as a result of the gop_interval, causes the bit rate to be exceeded.
How do we ensure that the bit rate is not exceeded even when an I-frame needs to be generated? Obviously, the quality will need to be reduced in order to achieve this
We're using IPP 5.3.2.068 and IPP samples 5.3.083 on Linux.
Upgrading to IPP 6 is not an option as this stage as we have significant investment in the IPP 5 API
We are measuring bit rate by calculating a rolling total of the number of output bytes from the encoder over a short interval of time (say, one second).
Our application is mobile telephony, where the amount of bandwidth is strictly limited. If the codec generates more than the available bandwidth allows, it will introduce latency. If the output bit rate continues to exceed the availale bandwidth, the latency will increase until some node in the media chain drops frames and triggers a resync.
We have tried dropping input frames to reduce the output data rate, but the codec increases the quality of the remaining frames. We have tried lowering the target maximum bit rate but this gives average lower quality video and still does not prevent the bit rate from being exceeded when an I-frame is generated.
I am particularly interested in this too. This is a show stopper forcircuit switched video telephony (3G phones) where the video path must not exceed 48kbps or the result will be latency and loss of lip synch.
p.s. we have some people working on this and any tips or pointers would be greatly appeciated. more than happy to report back once solved.
comment from our experts is that currently IPP H.264 encoder does not maintain bit rate over short period of time (say 1 second ~ 10 frames). There is no HDR support yet.
We recommend to play with VBR/CBR and GOP size.
In case of CBR (H264_RCM_CBR) BRC algorithm reaction time is faster (although it affect quality)