• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 1390 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.

HEVC WPP decoding

Jurgen Slowack
Prodigy 220 points

Hi,

I encoded a sequence using your HEVC encoder running on an octal DSP card. The HEVC encoder version used is C66x_h265venc_02_00_00_02_ELF. I have used the scripts provided within the MCSDK Video 2.2.0.45, with the following encoder config file 4848.LowDelay_codecParams1080p60.cfg. The encoded sequence (using 4 DSP's) is blue_sky_1080p25.123.

When using a third party decoder, single threaded decoding works fine but wavefront parallel decoding (using libde265) results in severe visual artefacts. These artefacts appear to be due to incorrect entry point offsets for WPP. Using the same decoder in combination with other encoders (e.g., x265) with WPP enabled results in no issues, which suggests that this an issue at the encoder side.

Best regards,

Jurgen

  • 0
    Expert 1230 points
    Hi Jurgen,

    I did not find issue decoding the stream using HM decoder.

    Can you please share the
    - First few decoded YUV sequences using single-thread libde265 decoder
    - First few decoded YUV sequences using multi-thread libde265 decoder containing artifact
    - Encoded stream using x265 encoder

    I was not able to download libde265 from the link in the above thread.

    Can you please share the libde265 library and brief the steps to use the libde265 decoder, so that we can reproduce the artifact at our end.

    Thanks and Regards,
    Palachandra M V
  • 0 in reply to Palachandra Venkataraju
    Prodigy 220 points

    Hi Palachandra,

    I did a clone of the libde265 git repository at (https://)github.com/strukturag/libde265 and built libde265 from source in Ubuntu 14.04, 64 bit. Here is the executable I use (remove the *.123 extension and execute in Linux 64 bit):dec265.123. Using this executable I decoded the file (from my previous post) using the following commands:

    ./dec265 --threads 16 blue_sky_1080p25.265 -q -o blue_sky_1080p25_libde265decoded_16threads.yuv

    -> here are frames 16, 17, 18, 19 and 20 of that yuv file (with obvious artefacts), rename *.123 to *.tar.bz2 and decompress: blue_sky_1080p25_libde265decoded_16threads_5frames.123

    ./dec265 --threads 0 blue_sky_1080p25.265 -q -o blue_sky_1080p25_libde265decoded_1thread.yuv

    -> here are frames 16, 17, 18, 19 and 20 of that yuv file (correct output), rename *.123 to *.tar.bz2 and decompress: blue_sky_1080p25_libde265decoded_1thread_5frames.123

    Using x265 (version 1.7-154-gfa91f51) with all default parameters (except for tune zerolatency)  I get the following encoded file of that same sequence: blue_sky_1080p25_x265encoded.123, which decodes fine using 16 threads in libde265.

    Best regards,

    Jurgen

  • 0 in reply to Jurgen Slowack
    Expert 1230 points
    Hi Jurgen,
    1. I downloaded the libde265 and tried to decode the stream blue_sky_1080p25.265
       - Observed warning message "Incorrect entry-point offsets" on single thread application
       - In case of multi-thread application Observed artifact in decoded sequence
       
    2. On encoding few more YUV streams, observed similar artifatcs while decoding using libde265 decoder, but was able to decode using HM Decoder and Interra Vega HEVC analyser without any warnings. I manually calculated the entry point offset it also appears to be fine.
    3. We observed that, on the first occurence of artifact in the decoded stream, emulation prevention is done on slice header. It looks like there is difference in the way emulation prevention is handled on slice header when WPP is enabled in case of HM and libde265 decoder
      
    4. In our encoder we are allocating 24 bits (3 bytes) for entry point offset and in most cases entry point offset will be less then 16 bits. Entry point offset pattern in our encoder will be like(00 AB CD 00 BC DE). The probabilty of emulation prevention happening is more in our encoder as there will be more zeros. 
       
    5. From the stream you shared it looks like x265 encoder uses variable size bit allocation for entry point offset calculation, based on the max value of entry point offset address which is similar to HM. Hence in most of the cases the total bits allocated will be <= 16 bits (2 bytes) and the pattern looks like (AB CD BC DE). The probabilty of emulation prevention occuring is less as the occurence of consecutive zeros is rare,  this may be the reason why artifacts are not observed in case of hevc encoded streams using x265 encoder.
       
    6. When we encode the same sequence in our encoder (where artifacts were observed earlier) by changing bit allocation from 24 to 16 bits for entry point offset calculation, we were able to decode the streams using libde265 decoder with out any warnings and artifacts in single thread and multi threaded scenarios. 
    Regards,
    Palachandra M V
  • 0 in reply to Palachandra Venkataraju
    Prodigy 220 points

    Hi Palachandra,

    Thank you for the extensive analysis. Can I manually change the bit allocation from 24 to 16 bits for entry point offset calculation in your encoder? (I did not find it in the config file)

    Best regards,

    Jürgen

  • 0 in reply to Jurgen Slowack
    Expert 1230 points

    Hi Jurgen,

    1. In our encoder bit allocation for entry-point offset is done in the code and is not a config parameter.

    2. Attached the encoder library which is build by changing the bit allocation for entry-point offset from 24 bits to 16 bits

    3. Attached encoder library can be used for testing purpose as entry-point offset exceeding 16 bits is not supported.

    Regards,

    Palachandra M V

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/lib.7z

  • 0 in reply to Palachandra Venkataraju
    Prodigy 220 points

    Hi Palachandra,

    Thanks for the update, I can confirm that this also works in my setup.

    Best regards

    Jurgen

  • 0 in reply to Palachandra Venkataraju
    TI__Guru* 81335 points

    Hi Palachandra,

    Thank you for your contribution to e2e. Your contribution is very much appreciated.

    Keep it up.