• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 100 subscribers
  • Views 387 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DM355: mpeg4enc rate control

Robin Iddon
Intellectual 380 points

Hi,

I'm having lots of trouble with the DM355 mpeg4enc rate control algorithms. Our application needs to limit the output bitrate and should not drop frames, so I've studied the behaviour of CVBR (IVIDEO_STORAGE) and VBR (IMP4ENC_VBR_RATEFIX).

CVBR (IVIDEO_STORAGE) seems to behave okay some of the time, but often it appears to go into a mode where it does not use the bitrate specified, but instead chooses a much lower bit rate. When it does this (which sometimes happens right from the start of encoding and seems to happen more often when the images to encode are fairly static), the output bitrate eventually drops to a level where it cannot encode sensibly at all as the I-frames are encoded with far too few bits. For example, I have some 640x360 recordings using CVBR at 2.2Mbps which on analysis are outputting 2.2Mbps quite consistently and look not too bad, but I have some other recordings using the same settings where from the start, the codec is outputting 1.5Mbps instead of 2.2Mbps and this drops towards 1.0Mbps over 3 minutes or so.

VBR (IMP4ENC_VBR_RATEFIX) appears to have more sensible behaviour at first. It constrains the bitrate over a longer period due to the gradual workings of it's algorithm and works okay for 15 minutes or so. However, for recordings longer than this, it appears to go into a mode where the bit rate suddenly becomes unconstrained. For example, if I limit it to 2.2Mbps, it will acheive this rate (measured over several seconds), but then starts outputting 6Mbps or so, which is roughly what IVIDEO_NONE produces for this resolution.

I'm using dm355_codecs_1_13_000.

  • 0
    Intellectual 380 points

    Sorry for the double post. I didn't understand that my posts had been moved to the new? coded forum.

  • 0 in reply to Robin Iddon
    TI__Genius 9490 points

    Robin,

    The post was moved here becasue based on the following guidelines, your question belongs in this category so the proper audience can look at your issue.

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/dm3x/f/100/t/37487.aspx

    regards,

    mA

  • 0 in reply to Miguel A. Alanis
    Intellectual 380 points

    Thanks - any idea when/if anybody from TI will look at this and perhaps give us some insight into what's going wrong?

     

    Best wishes,

     

    Robin

     

  • 0 in reply to Robin Iddon
    TI__Genius 17215 points

    Robin,

    We have started looking into the issue. Will respond in about 1 weeks time.

    regards

    Yashwant

  • 0 in reply to Yashwant Dutt
    TI__Genius 17215 points

    Robin,

    We have a newer version of DM355 codecs, viz 1.14.002. The first issue was not reproduced in this version. We advice migrating to this newer version. But this version is not published on ti website. If you can send details of your contact TI FAE, we can work with him to provide you the newer 1.14.002 version of codecs. 

    regards

    Yashwant 

  • 0 in reply to Yashwant Dutt
    Intellectual 380 points

    Hi Yashwant,

    I've sent you the requested contact information in a "friend request".

  • 0 in reply to Robin Iddon
    TI__Genius 17215 points

    Hi Robin,

    You would have got access to an TI FTP site based on the email id you provided. Please login as per the instruction. The codec release is shared at

    /DM355_legacy_releases/ver1_14_002/

    Pls try using that codec and recheck your issue.

    regards

    Yashwant

  • 0 in reply to Yashwant Dutt
    Intellectual 380 points

    I've got the software. Thanks!

    I'll try it out during the next week and let you know how it goes.

    If I'm still having problems, I'll try the new IMP4ENV_CVBR_LBR[12] algorithms, although I'm not sure if they are intended for my usage scenario or for much lower bitrates.

  • 0 in reply to Robin Iddon
    Intellectual 380 points

    Hi,

    I've tested the new codec and can confirm that using CVBR (IVIDEO_STORAGE), the codec no longer seems to go into a mode that uses a bit-rate much lower than is required to sensibly encode I-frames. This solves our worst problems, so thanks for the help.

    I'm still having difficulties with the behaviour of all the other rate control algorithms. This is because they all in their various ways maintain the target bit-rate over a long period, but do not constrain the bit-rate over shorter periods. For example, if the target bit-rate is 2Mbps, the algorithms may choose to produce 1.8Mbps for 30s (say) and then when there is lots of movement, produce 5Mbps for a few seconds. I've seen this behaviour at least in VBR and the new CVBR_LBR algorithms.

    This causes problems for us because when trying to process this higher bit-rate data, we run out of CPU cycles required to continue capturing without dropping any frames. In our system, experimentation has shown that we cannot handle bursts that exceed about 4Mbps.

    It would be really nice to be able to use these other algorithms as our target bit-rate only needs to be achieved over a period of hours and allowing the bit-rate to drop when not required gives better quality results over all. If the algorithms supported a max bit-rate in addition to the target bit-rate so that the bit-rate is controlled during bursts, then we would be able to use them.

  • 0 in reply to Robin Iddon
    Intellectual 340 points

    Hi,

    These rate control algorithms do not support Max bit rate.

    One of the option to have tighter control on bitrate can be by reducing the size of VBV_Buffer (using extended parameter).

    You can set the value of VBV_buffer size to half or one fourth of the default value (formula is given in the User's Guide to calculate the default value).

    So if there is sudden burst, it will drop few frames to reduce the bitrate deviation.

     

    Regards,

    Tej