This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
I am working on a DM368 platform and encoding H.264 at 1080P / 30 / 6Mbps / CBR. The encoded NAL stream is placed in an MPEG2 TS and sent over the network to a broadcast decoder. The decoder is very picky about the data being exact CBR. Usually we could insert NULL packets into the stream to make it CBR, however we don't much additional memory bandwidth and/or CPU to enlarge the stream enough to account for the spikes in the IDR frame size.
I have tried various values for rcQMinI and rcQMaxI, and have also tried using rcAlgo 4 (constant frame size) rather than 5, though I have read that rcAlgo 4 is not suitable for 1080P resolution. The rcAlgo 4 does work however, until I have heavy scene changes, at which point the frame sizes start changing. It also produces heavily quantized images, which is sort of expected.
So, on to my question: Does TI have a recommended set of encoder settings for producing a high quality CBR NAL stream, where the IDR frame size does not spike so high?
Have you tried rcAlgo=0? This rate control mode corresponds to CBR. This should not cause a spike in bitrate for IDR frames.
You can refer to the wiki link below for more details on rate control
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Adithya Banninthaya:
I should have mentioned I also tried rcAlgo of 0, and have read that wiki page previously. With rcAlgo 0 the problem is not as bad, but it is still there. If I have a still scene I can see the P frames are ~14-26Kbytes and the IDR frame is around 99Kbytes.
Here is a simple log with the timing and byte count from the call to VIDENC1_process, with rcAlgo set to 0. Is this result expected?
H264 - Generated 99498 bytes in 34282 us - IDR FrameH264 - Generated 20195 bytes in 30506 usH264 - Generated 12431 bytes in 30236 usH264 - Generated 15156 bytes in 30169 usH264 - Generated 14593 bytes in 30183 usH264 - Generated 14891 bytes in 30179 usH264 - Generated 13722 bytes in 30147 usH264 - Generated 17043 bytes in 30209 usH264 - Generated 21131 bytes in 30206 usH264 - Generated 20079 bytes in 30222 usH264 - Generated 24542 bytes in 30219 usH264 - Generated 26622 bytes in 30275 usH264 - Generated 25916 bytes in 30225 usH264 - Generated 25520 bytes in 30272 usH264 - Generated 26326 bytes in 30306 usH264 - Generated 25040 bytes in 30227 usH264 - Generated 26815 bytes in 30277 usH264 - Generated 25181 bytes in 30240 usH264 - Generated 25782 bytes in 30249 usH264 - Generated 20807 bytes in 30348 usH264 - Generated 25211 bytes in 30180 usH264 - Generated 25766 bytes in 30218 usH264 - Generated 24624 bytes in 30210 usH264 - Generated 24172 bytes in 30214 usH264 - Generated 25468 bytes in 30198 usH264 - Generated 25029 bytes in 30252 usH264 - Generated 25764 bytes in 30300 usH264 - Generated 25558 bytes in 30226 usH264 - Generated 25968 bytes in 30281 usH264 - Generated 26234 bytes in 30311 usH264 - Generated 99502 bytes in 34305 us - IDR FrameH264 - Generated 18923 bytes in 30455 usH264 - Generated 12666 bytes in 30215 usH264 - Generated 12494 bytes in 30250 usH264 - Generated 14856 bytes in 30213 usH264 - Generated 14860 bytes in 30190 usH264 - Generated 14345 bytes in 30110 usH264 - Generated 16347 bytes in 30196 usH264 - Generated 15562 bytes in 30087 usH264 - Generated 27337 bytes in 30191 usH264 - Generated 26005 bytes in 30247 usH264 - Generated 24950 bytes in 30230 usH264 - Generated 25802 bytes in 30217 usH264 - Generated 24880 bytes in 30220 usH264 - Generated 24804 bytes in 30205 usH264 - Generated 26654 bytes in 30240 usH264 - Generated 26686 bytes in 30271 usH264 - Generated 21692 bytes in 30283 usH264 - Generated 25058 bytes in 30214 usH264 - Generated 25643 bytes in 30293 usH264 - Generated 25481 bytes in 30167 usH264 - Generated 25480 bytes in 30223 usH264 - Generated 24717 bytes in 30268 usH264 - Generated 25290 bytes in 30264 usH264 - Generated 24946 bytes in 30231 usH264 - Generated 26320 bytes in 30260 usH264 - Generated 25884 bytes in 30176 usH264 - Generated 25552 bytes in 30227 usH264 - Generated 19777 bytes in 30263 usH264 - Generated 24490 bytes in 30287 usH264 - Generated 99429 bytes in 34284 us - IDR Frame
In reply to Chris Richardson77843:
For a static sequence I frame will require considerable amount of bits and p-frames will require very less bits. Trying to reduce the bits given to I-frame say in the above example bringing it down to 30000 will degrade the quality of i-frames and hence the overall visual perception
You could set the value of LBRmaxpicsize to set 20. This should reduce the bits given to I-frame and have some impact on quality but that will be trade off to meet the criteria.
Thank you for your time and your response. I have tried setting LBRmaxpicsize to 20. It does produce a fairly even bit stream (and using 10 it is more even still, which makes sense), but now I observe that the encode timing is too slow for real time. Is this also expected? Here is a log using LBRmaxpicsize of 10:
H264 - Generated 24889 bytes in 34031 usH264 - Generated 24890 bytes in 32494 usH264 - Generated 24905 bytes in 32734 usH264 - Generated 25220 bytes in 35792 usH264 - Generated 25140 bytes in 33881 usH264 - Generated 25197 bytes in 33578 usH264 - Generated 25086 bytes in 34024 usH264 - Generated 25071 bytes in 34478 usH264 - Generated 25004 bytes in 31870 usH264 - Generated 25116 bytes in 33227 usH264 - Generated 24953 bytes in 33212 usH264 - Generated 24875 bytes in 34461 usH264 - Generated 25050 bytes in 31747 usH264 - Generated 24908 bytes in 33310 usH264 - Generated 24936 bytes in 33937 usH264 - Generated 24893 bytes in 33948 usH264 - Generated 24887 bytes in 31847 usH264 - Generated 24877 bytes in 33295 usH264 - Generated 24891 bytes in 34181 usH264 - Generated 25129 bytes in 34572 usH264 - Generated 24876 bytes in 35000 usH264 - Generated 24942 bytes in 31882 usH264 - Generated 24918 bytes in 33885 usH264 - Generated 24813 bytes in 33500 usH264 - Generated 24987 bytes in 34695 usH264 - Generated 24874 bytes in 31922 usH264 - Generated 24913 bytes in 33496 usH264 - Generated 24899 bytes in 34418 usH264 - Generated 24841 bytes in 34508 usH264 - Generated 24947 bytes in 31816 usH264 - Generated 24991 bytes in 32615 usH264 - Generated 24895 bytes in 33739 usH264 - Generated 24847 bytes in 33875 usH264 - Generated 25255 bytes in 35800 usH264 - Generated 25141 bytes in 32021 usH264 - Generated 25214 bytes in 33093 usH264 - Generated 25172 bytes in 34091 usH
Encoding perofrmance should not reduce. Are you sure nothing else is changed?
You are correct, I had also set the rcAlgo to 4 in that test. When I set the rcAlgo to 5 or 0 and LBRmaxpicsize to 10 I get reasonable timing (though still not < 30ms per frame). However the sizes still vary enough that my decoder will not properly receive it. If I add filler NAL units of type 12 to make the frames all the exact same size the decoder will receive the stream. Overall, this is not a good solution, as the IDR frame is very quantized and still produces a "breathing" artifact.
Is there any other way to reduce the breathing effect in this mode?
Also, is there any way to tell the codec to output a fixed maximum size per frame and never go above that? I see even with LBRmaxpicsize set to 10 that the picture size can go above the size specified by bitrate divided by frame rate.
When you say breathing artifact, do you mean I frame quality is bad and it gets progressively better during P frames and then again gets bad at next I-frame?
This is because bits for I-frame are not sufficient. I had mentioned it earlier, if generating the same amount of bits for each frame is criteria, then quality of I-frame will suffer. I guess this is the trade off. Can't the I/IDR frames be treated as special at the decoder and excusing them for consuming more bits?
What is the maxQp you are setting?
You are correct, the breathing artifact is indeed the quality during the I frame, which then gets better during P frames. I was wondering if there was a way to reduce this effect. I am leaving the QP params at their defaults, which are the following:
intra frame QP : 28 inter P-frame QP : 28 initial r.c. QP : 28 rate control QMax : 45 rate control QMin : 0 rate control QMax I : 42 rate control QMin I : 0
Do you have any recommendations I could try?
Thanks a lot for your persistence and help!
Well I marked the LBRmaxpicsize post as the answer since this thread has helped me get closer to my goal. I would still like to reduce the "breathing" effect if possible, but I will start a new post for that.
Thank you for the help!
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.