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.

About your HEVC encoder version 1.0.0.44

We evaluated your HEVC version 1.0.0.44 and have the following findings. 1.QP does not seem to change within a given encoded picture. 2.CU as B is rarely used in B pictures. 3.CU as skip for relatively static area is also less frequently used. CUs for some of these areas are even intra-encoded in P and B pictures. 4.QpI, QpB and QpOffsetB in the configuration file have big impact on the quality of the encoded video even though their corresponding ranges specified min and max Qp is sufficient large. This might indicate that the quality of the encoded pictures can be improved if the QP estimation is more accurate rather than heavily dependent on user input. 5.If we give the encoder enough flexibility to choose QP as in your sample cfg file, the quality of the encoded video is inferior to your H.264 encoder where we restricted the QP in a relative smaller range. (We have to restrict QP in your H.264 encoder to a smaller range to achieve acceptable quality as it too suffers this problem, at least for some earlier versions.)

Before item 4 above is resolved, we find it is difficult to achieve (sufficiently) better quality even at the same bit rate as your H.264. I was wondering if some of the following could be useful for your rate control:

a)      Allocate significantly more bits for I picture than P, and significantly more for P than B.

b)      Do a complexity analysis for each coding tree;

c)       then allocate target bits according to the complexity;

d)      Calculate average complexity and estimate average Qp for the whole picture. Varying your CT QP according to the variation of the complexity of the current CT.

e)      When coding the CT, compare the number of bits generated for the current CT and the current picture and GOP so far against the corresponding targeted to adjust QP for the next CT.

Herewith I attached some your H.265 and H.264 encoded as well as PSNR and H.265 cfg files.

Regards,

Dongning

6761.2015-02-23_TI_H265_Feedback (2).zip

  • Further to my previous email, it seems that setting maxDeltaQP to be nonzero can make encoder use non-constant QP for a picture. I tried this setting a few times but the code always crashes on my C6678 eval board.

    Dongning
  • Hi Dongning, thanks a lot for your comments and pointers. We are currently finishing HEVC GA 2.0 (we should have a new MCSDK video drop in the next couple of weeks with it) which has improved quality. We will check if your feedback is already addressed on GA 2.0 and let you know. Also let us know if you want to have this new HEVC encoder drop before it is packaged on MCSDK video.

    thank you,
    Paula
  • Hi Paula,

    Thank you for your reply and update.

    Yes, we would be very grateful for receiving the encoder drop before it is packaged into MCSDK vide.

    I further played with maxDeltaQP parameter with your current encoder, and realized that the values I used is not within the supported range of [-5, 5], which could be the reason of the crash. However, for my testing the encoder still uses the same QP within an encoded picture for any value in this range.

    Regards,

    Dongning
  • Dear Dongning,

    Following is the reply regarding your query about HEVC encoder 1.0.0.44 quality.

    1. Please enable SubFrameRC flag to modify QP within picture. This modifies QP with in picture.
    2. Please set "enableBiPredMode" flag in config to enable bi-prediction modes.
    3. You can observe improved quality in our latest encoder release.
    4. Currently we consider complexity of input to estimate QP for current picture. However for further frames, along with complexity of current picture, data from previous encoded picture is also considered for QP estimation.
    5. Please set qpI as "-1" to allow encoder to calculate the initial I-Frame QP based on input frame complexity. If we observe average Qp across the stream is ~26, but it was set to 33 for I frame which becomes reference frame. This will impact the quality as number of encoded frames are less.

    Regarding your further inputs to rate-control.

    (a) Already bit allocation is taken care based on picture type.
    (b), (c) & (d) Currently we are not supporting to modify QP at each CTU/CU level due to multi-core implications. Please enable PRC in the config, which modifies QP at CTU level. PRC flag provides encoder flexibility to modify QP at CTU level which improves subjective quality rather than objective quality.
    (e) In case of SubFrameRC, bit allocation is computed based on previous encoded picture and previous encoded rows of current picture.

    Regards

    Kuladeepak

  • Hi Dongning, please see attached latest HEVC encoder.

    0676.C66x_h265venc_02_00_00_00_ELF.bin

    Thank you,

    Paula

  • Hi Paula,

    Thank you for the encoder. But this seems to be neither C6678 library nor C6678 executable. Is it for linux platform? How should I use it?

    Regards,

    Dongning
  • Hi Dongning, now attached Win installer =)2642.C66x_h265venc_02_00_00_00_ELF.exe

    Thank you,

    Paula

  • Hi Paula,

    thank you for the windows installer. I played with the new library and see some improvement over the previous version. In one of my tests, I see about 25% bit saving for about the same picture quality in comparison to your H.264 encoder. What typical bit rate reduction is achievable from your experiences?

     

    By the way, configuration parameters enablePRC = 1 and SubFrameRC = 1 do not seem to be supported. Either of these configuration will cause this version of encoder to complain static parameter setup problem.

     

    Regards,

     

    Dongning

  • Hi Dongning, I will let the codec team help you to correctly enable PRC and SubFrameRC in the configuration file. About your bitrate compression saving, which resolution and metrics are you using for comparison? I guess SD and PSNR?

    thank you,

    Paula

     

  • Hi Dongning,

        To resolve the create fail. I need some other parameter value like (RateControlPreset, enableTiles, sliceCodingMode, sliceCodingArg, inputWidth, disableVirtualTileDependency, nLCUSize).

    So it would be better, if you share the config file.

    Regards

    Kuladeepak

  • Hi Kuladeepak,

     

    Thank you for your reply.

    The attached is the config file which generates "Check Create-time static parameter settings" message. It will not generate this message if SubFrameRC is set to 0. The same applies to "enablePRC".

    Regards,

     

    Dongning

    0825.encoder640x360_1.cfg

  • Hi Dongning,

        In given config 2 parameter needs to be changed

    1) rateControlPreset = 5 (4 -> Fixed Qp, 5-> UserDefined)

    2) disableVirtualTileDependency = 0 (When this enabled Qp variation within frame is disabled).

    Some recommendations in config for better quality,

    1) maxCUDepth can be made to 3, it increases the CTB Depth.

    2) intraCodingPreset and enableStrongIntraSmoothing can be made 1.

    Regards

    Kuladeepak

  • Hi Kuladeepak,

    Thank you for your support.

    With the suggested parameter settings, the encoder generates a little bit more bits at the same target bit rate. If I set the target bit rate lower (i.e., 1.6 mbps instead of 1.8 mbps), it generates about the same number of bits with about the same average PSNRfor 30 frame test.

    From your experiences, what are the typical bit savings at the same picture quality in comparison to your H.264 encoder?

    Regards,

    Dongning
  • Hi Dongning,

         Rate control takes some time to stabilize. It would be better to encode 4*30(4 sec) number of frames.

    Typically we were observing 40% bit savings at same picture quality when compared with H264 encoder.

    Regards

    Kuladeepak

  • Hi Dongning we see ~40% of bitrate saving compared our IVAHD H264HP, for HD resolutions, using PSNR as a VQ metric.
    Thank you,

    Paula
  • Hi Paula and Kuladeepak,

    Thank you for your reply.

    I did several tests for a sequence of 120 frames of size 640x360 by using your H.265 of version 2.0.0.0. For this test video sequence I only see about  23% bit saving at about the same PSNR in comparison to your H.264 encoder. Here for H.265 encoding, only the first picture is IDR, while for H.264 IDR happens in an interval of 15 frames (i.e., GOP size is 15). If the H.265 encoder is also configured to generate the same GOP pattern, the improvement should be less as more IDR encoded pictures are generated. Herewith I attached both encoded streams and their corresponding PSNR files as well as cfg file used for H.265 encoding.

     

    I was wondering whether you know this performance improvement for this size and bit rate is typical. If not, how should we set configuration parameters to achieve a better performance.

     

    Regards,

     

    Dongning

    8345.2015-03-06_TI_H265_feedback.zip

  • Hi Dongning

    I missed out to mention other quality controling flag.
    1) EncodingPreset = 1
    2) enableStrongIntraSmoothing = 1
    3) enableFastIntraAlgo = 0

    Can you please provide the input yuv and 264 config with which we can do detailed anaylsis and get back to you.

    Regards
    Kuladeepak

  • Hi Kuladeepak,

    I could not remember what config parameters were used for generating the H.264 stream sent you in my previous posting, so I did a new test with similar GOP structure. The encoded bitstreams, config and PSNR files are attached in this posting. The source video sequence can be downloaded from the following link for a limited period of time:

    www.sendspace.com/.../vk1hr5

    In this new test, the version of your H.264 encoder is 01.00.03.00, while that of your H.265 encoder is 2.0.0.0. The bit saving is about 12% with the following average PSNR

    H.264: SNR_Y :35.13dB  SNR_U :45.35dB  SNR_V :45.34dB

    H.265: SNR_Y :35.06dB  SNR_U :44.60dB  SNR_V :44.77dB

    How can we get a significantly better performance from your H.265, by configuration parameters or future update?

    Regards,

    Dongning

     1325.2015-03-11_TI_comparison.zip

     

     

     

  • Hi Dongning,

        Thanks for providing the yuv and configs.

    We have analyzed and changed the 265 config for better performance and we were able to observe ~25% bit saving with 264.

    PSNR Y H265 :- 35.15    Bitrate :- 1.875 Mbps

    PSNR Y H264 :- 35.126  Bitrate :- 2.5 Mbps

    And we are continuing the analyses for better performance. Please find the updated config file for 265 attached.

    Regards

    Kuladeepak

    2043.encoder640x360_h265.cfg