• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 101 subscribers
  • Views 3672 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DM36x H.264 IDR frame size under CBR

Chris Richardson77843
Intellectual 435 points

Hi,

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?

Thanks,

Chris Richardson

  • 0
    TI__Intellectual 1930 points

    Chris,

    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

    http://processors.wiki.ti.com/index.php/DM36x_Rate_Control_Modes

  • 0 in reply to Adithya Banninthaya
    Intellectual 435 points

    Hi Adithya,

    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 Frame
    H264 - Generated   20195 bytes in      30506 us
    H264 - Generated   12431 bytes in      30236 us
    H264 - Generated   15156 bytes in      30169 us
    H264 - Generated   14593 bytes in      30183 us
    H264 - Generated   14891 bytes in      30179 us
    H264 - Generated   13722 bytes in      30147 us
    H264 - Generated   17043 bytes in      30209 us
    H264 - Generated   21131 bytes in      30206 us
    H264 - Generated   20079 bytes in      30222 us
    H264 - Generated   24542 bytes in      30219 us
    H264 - Generated   26622 bytes in      30275 us
    H264 - Generated   25916 bytes in      30225 us
    H264 - Generated   25520 bytes in      30272 us
    H264 - Generated   26326 bytes in      30306 us
    H264 - Generated   25040 bytes in      30227 us
    H264 - Generated   26815 bytes in      30277 us
    H264 - Generated   25181 bytes in      30240 us
    H264 - Generated   25782 bytes in      30249 us
    H264 - Generated   20807 bytes in      30348 us
    H264 - Generated   25211 bytes in      30180 us
    H264 - Generated   25766 bytes in      30218 us
    H264 - Generated   24624 bytes in      30210 us
    H264 - Generated   24172 bytes in      30214 us
    H264 - Generated   25468 bytes in      30198 us
    H264 - Generated   25029 bytes in      30252 us
    H264 - Generated   25764 bytes in      30300 us
    H264 - Generated   25558 bytes in      30226 us
    H264 - Generated   25968 bytes in      30281 us
    H264 - Generated   26234 bytes in      30311 us
    H264 - Generated   99502 bytes in      34305 us - IDR Frame
    H264 - Generated   18923 bytes in      30455 us
    H264 - Generated   12666 bytes in      30215 us
    H264 - Generated   12494 bytes in      30250 us
    H264 - Generated   14856 bytes in      30213 us
    H264 - Generated   14860 bytes in      30190 us
    H264 - Generated   14345 bytes in      30110 us
    H264 - Generated   16347 bytes in      30196 us
    H264 - Generated   15562 bytes in      30087 us
    H264 - Generated   27337 bytes in      30191 us
    H264 - Generated   26005 bytes in      30247 us
    H264 - Generated   24950 bytes in      30230 us
    H264 - Generated   25802 bytes in      30217 us
    H264 - Generated   24880 bytes in      30220 us
    H264 - Generated   24804 bytes in      30205 us
    H264 - Generated   26654 bytes in      30240 us
    H264 - Generated   26686 bytes in      30271 us
    H264 - Generated   21692 bytes in      30283 us
    H264 - Generated   25058 bytes in      30214 us
    H264 - Generated   25643 bytes in      30293 us
    H264 - Generated   25481 bytes in      30167 us
    H264 - Generated   25480 bytes in      30223 us
    H264 - Generated   24717 bytes in      30268 us
    H264 - Generated   25290 bytes in      30264 us
    H264 - Generated   24946 bytes in      30231 us
    H264 - Generated   26320 bytes in      30260 us
    H264 - Generated   25884 bytes in      30176 us
    H264 - Generated   25552 bytes in      30227 us
    H264 - Generated   19777 bytes in      30263 us
    H264 - Generated   24490 bytes in      30287 us
    H264 - Generated   99429 bytes in      34284 us - IDR Frame

    Thanks,

    Chris Richardson

  • 0 in reply to Chris Richardson77843
    TI__Intellectual 1930 points

    Chris,

    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.

    Regards

    Adithya

  • 0 in reply to Adithya Banninthaya
    Intellectual 435 points

    Hi Adithya,

    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 us
    H264 - Generated   24890 bytes in      32494 us
    H264 - Generated   24905 bytes in      32734 us
    H264 - Generated   25220 bytes in      35792 us
    H264 - Generated   25140 bytes in      33881 us
    H264 - Generated   25197 bytes in      33578 us
    H264 - Generated   25086 bytes in      34024 us
    H264 - Generated   25071 bytes in      34478 us
    H264 - Generated   25004 bytes in      31870 us
    H264 - Generated   25116 bytes in      33227 us
    H264 - Generated   24953 bytes in      33212 us
    H264 - Generated   24875 bytes in      34461 us
    H264 - Generated   25050 bytes in      31747 us
    H264 - Generated   24908 bytes in      33310 us
    H264 - Generated   24936 bytes in      33937 us
    H264 - Generated   24893 bytes in      33948 us
    H264 - Generated   24887 bytes in      31847 us
    H264 - Generated   24877 bytes in      33295 us
    H264 - Generated   24891 bytes in      34181 us
    H264 - Generated   25129 bytes in      34572 us
    H264 - Generated   24876 bytes in      35000 us
    H264 - Generated   24942 bytes in      31882 us
    H264 - Generated   24918 bytes in      33885 us
    H264 - Generated   24813 bytes in      33500 us
    H264 - Generated   24987 bytes in      34695 us
    H264 - Generated   24874 bytes in      31922 us
    H264 - Generated   24913 bytes in      33496 us
    H264 - Generated   24899 bytes in      34418 us
    H264 - Generated   24841 bytes in      34508 us
    H264 - Generated   24947 bytes in      31816 us
    H264 - Generated   24991 bytes in      32615 us
    H264 - Generated   24895 bytes in      33739 us
    H264 - Generated   24847 bytes in      33875 us
    H264 - Generated   25255 bytes in      35800 us
    H264 - Generated   25141 bytes in      32021 us
    H264 - Generated   25214 bytes in      33093 us
    H264 - Generated   25172 bytes in      34091 us
    H

    Thanks,

    Chris Richardson

  • 0 in reply to Chris Richardson77843
    TI__Intellectual 1930 points

    Chris,

    Encoding perofrmance should not reduce. Are you sure nothing else is changed?

  • 0 in reply to Adithya Banninthaya
    Intellectual 435 points

    Hi Adithya,

    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.

    Thanks,

    Chris

  • 0 in reply to Chris Richardson77843
    TI__Intellectual 1930 points

    Hi Chris,

    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?

  • 0 in reply to Adithya Banninthaya
    Intellectual 435 points

    Hi Adithya,

    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!

    Chris

  • 0 in reply to Chris Richardson77843
    Intellectual 435 points

    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!