Opened 8 years ago

Closed 8 years ago

#994 closed defect (fixed)

Emulation prevention bytes igonred by HM decoder to calculate entry_point_offset[ i ] when entropy_coding_sync_enabled_flag is enabled.

Reported by: chethan879 Owned by:
Priority: major Milestone: HM-10.1
Component: HM Version: HM-9.1
Keywords: emulation prevention, entropy_coding_sync_enabled_flag Cc: fbossen, ksuehring, davidf, jct-vc@…

Description

The section 7.9.4.1 of standard says that emulation prevention bytes are included to calculate entry_point_offset[i] where i = 0 to num_entry_point_offsets, when entropy_coding_sync_enabled_flag is equal to 1. However it seems like HM 9.1 decoder is reading the substream in TComInputBitstream::extractSubstream() (after having removed the emualtion prevention bytes). This means there implementation assumes that entry point offset does not include the number of emulation prevention bytes.
As a result decoder starts decoding a row at wrong offset.

Attachments (2)

entropy_sync_enabled.265 (426 bytes) - added by chethan879 8 years ago.
stream with entropy sync enabled in which HM 9.1 decoder crashes after decoding one CTB row. The docoding of second row starts at wrong offset as it ignores the emuation prevention bytes in the first CTB row.
entry_point_offset_wpp_hm-9.1.patch (9.5 KB) - added by kiranmisra 8 years ago.
Proposed patch for substream entry point information

Download all attachments as: .zip

Change History (13)

comment:1 Changed 8 years ago by DefaultCC Plugin

  • Cc jct-vc@… added

comment:2 Changed 8 years ago by chethan879

  • Priority changed from minor to major

comment:3 Changed 8 years ago by ksuehring

I just decoded with HM-9.1. As far as I know, these offsets are not used in the decoder. Are you using a modified software like the one in #942?

Changed 8 years ago by chethan879

stream with entropy sync enabled in which HM 9.1 decoder crashes after decoding one CTB row. The docoding of second row starts at wrong offset as it ignores the emuation prevention bytes in the first CTB row.

comment:4 Changed 8 years ago by chethan879

I am sorry i had attached a wrong file. I have replaced the older file with bitstream which crashes when tried decoding with HM 9.1 and the description holds good for this file. I confirm that i am using unmodified version of HM 9.1 decoder. The following code snippet is used to extract substream based on entry_point_offset.

Function - Void TDecGop::decompressSlice(TComInputBitstream* pcBitstream, TComPic*& rpcPic)

  UInt uiNumSubstreams = pcSlice->getPPS()->getEntropyCodingSyncEnabledFlag() ? pcSlice->getNumEntryPointOffsets()+1 : pcSlice->getPPS()->getNumSubstreams();

  // init each couple {EntropyDecoder, Substream}
  UInt *puiSubstreamSizes = pcSlice->getSubstreamSizes();
  ppcSubstreams    = new TComInputBitstream*[uiNumSubstreams];
  m_pcSbacDecoders = new TDecSbac[uiNumSubstreams];
  m_pcBinCABACs    = new TDecBinCABAC[uiNumSubstreams];
  for ( UInt ui = 0 ; ui < uiNumSubstreams ; ui++ )
  {
    m_pcSbacDecoders[ui].init(&m_pcBinCABACs[ui]);
    ppcSubstreams[ui] = pcBitstream->extractSubstream(ui+1 < uiNumSubstreams ? puiSubstreamSizes[ui] : pcBitstream->getNumBitsLeft());
  }

The value of entry_point_offset is used to extract the substream and HM 9.1 decoder does not include emulation prevention bytes.

Last edited 8 years ago by ksuehring (previous) (diff)

comment:5 follow-up: Changed 8 years ago by kiranmisra

Would it be possible to share the exact location of the emulation prevention bytes (in the NALU) and the CTB row sizes as seen by the encoder (in entropy_sync_enabled.265)? If the bitstream is generated using HM, could you please share the HM version and encoder configuration used so that the problem can be reproduced.

comment:6 in reply to: ↑ 5 Changed 8 years ago by chethan879

Replying to kiranmisra:

Would it be possible to share the exact location of the emulation prevention bytes (in the NALU) and the CTB row sizes as seen by the encoder (in entropy_sync_enabled.265)? If the bitstream is generated using HM, could you please share the HM version and encoder configuration used so that the problem can be reproduced.

I am not using HM encoder to generate bitstream. I am using a fixed CTB size of 64x64 and encoding entire frame as single slice. The uploaded file is single IDR frame(blank content) The offset of first emulation prevention bytes in slice data (we can ignore emulation prevention bytes in header data as this will not affect entry_point_offset) is listed below
First emulation prevention byte offset from frame start - 150
FIrst emulation prevention byte offset from start of slice data - 18
This emualtion prevention byte is part of the first CTB row (which was successfully parsed).

I have tested our encoder's entropy sync feature for other contents and i dont see any mismatch between our encoder and HM decoder(version 9.1). I did not observe emulation prevention bytes in slice data of streams which passed the test. However when i try to encode blank frame( this increases possiblity of emulation prevention bytes) i see mismatch in trace of decoder at start of second row. The decoder starts decoding the second row at wrong offset, the difference in offset of start of actual second row data and offset where decoder starts decoding is same as number of emulation prevention bytes inserted in first CTB row.

Changed 8 years ago by kiranmisra

Proposed patch for substream entry point information

comment:7 Changed 8 years ago by kiranmisra

Thank you for the explanation of the contents within the bitstream entropy_sync_enabled.265. Attached is a proposed patch which keeps track of emulation prevention bytes within a NALU. The decoder uses this information to update the entry point information. The proposed patch also updates the encoder to include emulation prevention bytes when determining entry point information for wavefront substreams.

comment:8 Changed 8 years ago by chethan879

Thank you for the patch. The problem seems to have got resolved with this patch. Please let me know when this change gets reflected in main release of HM.

comment:9 Changed 8 years ago by ksuehring

  • Milestone set to HM-10.1
  • Resolution set to fixed
  • Status changed from new to closed

I have adapted the patch to HM-10.0-dev and applied it in r3363

comment:10 Changed 8 years ago by ksuehring

  • Resolution fixed deleted
  • Status changed from closed to reopened

The applied patch has bug that results in failure to count consecutive start code emulations properly.

comment:11 Changed 8 years ago by ksuehring

  • Resolution set to fixed
  • Status changed from reopened to closed

The code has been fixed in r3376. The fix also resolves the same issue for tiles.

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • David Flynn(Subscriber)
  • Frank Bossen(Subscriber)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Subscriber, Participant, Always)
  • Kiran Misra(Participant)