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.

DM365 H.264 High Profile Encoder API

Expert 1130 points

Where can I get the User Guide for the H.264 High Profile Encoder? I have the H.264 Baseline Profile Encoder User Guide for the DM6446, but I'm figuring the XDM arguments and enumerators differ.

  • You should be able to find the appropriate document in your DVSDK install for DM365, for example dvsdk_xx_xx_xx_xx\dm365_codecs_xx_xx_xx\packages\ti\sdo\codecs\h264enc\docs\h264_encoder_dm365_userguide.pdf.

  • For a more direct answer, I have attached the version from the DVSDK beta (2.10.00.13) here, note that as this is beta this is subject to change, but it should give you some idea of what to expect.

    h264_encoder_dm365_userguide.pdf
  • Hey Bernie,

                         It looks like the H.264 Encoder in the newer DM365 Beta SDK (2.10.00.13) still does not support YUV 4:2:2 interleaved input - is this correct? The reason why i ask is that any video encoding involving raw video capture always requires using the resizer to do the 4:2:2 to 4:2:0 conversion, and consequently, the output widths of the downscaled stream has to be a multiple of 32.

    I don't mind using the resizer, but I'm stuck with the x32 limitation.

  • Jerry,

    I must admit I am rather new to DM365, but I suspect the 32- byte limitation you are referring to is die to the DMA engine used in our video processing blocks (similar to other DaVinci platforms).  This means that ideally, if you are using 16-bit (2 byte) YCbCr pixels, you would want to work with mutiples of 16 pixels (2 bytes x 16 = 32 bytes alignment) for optimal efficiency.  However, if you are working with resolutions that are not 32 byte aligned what I have seen done in the past is

    1) crop off some of the line length to make it 32 byte aligned (e.g. use 704 line width instead of 720 assuming 1 pixel per byte)

    2) manipulate memory so that you have some padding at the end of each line to make it 32-byte aligned (line length becomes 736 instead of 720); yes, you will resize some meaningless data, but as long as you keep this in mind, you can decide to save only the meaningful data to a file.  Alternatively, if you are displaying, the fact that you are reading in 736 bytes of data via DMA engine does not mean you have to display all of it, you can set your video display window to 720 (underneath, the DMA engine will still read-in 736 bytes, but will only display 720).

  • Hey Juan,

                      Yes, its a pseudo memory limitation (the Y, and CbCr Offset addition register in the resizer module (see register RZA_SDR_Y_OFT) has to be a multiple of 32).

    The eventual solution as you mentioned is a cropping or a memory padding solution, either of which would require a 2-D DMA operation to get done, before piping it to the resizer. Unfortunately, this would incur a small bit of a latency hit as I'd have to deviate from the current setup of CCDC directly piping to the resizer and then to SDRAM.