Opened 10 years ago Closed 10 years ago #1349 closed defect (fixed)HM cannot decode the 1st buffering period SEI message.
Description
We found that current HM trunk cannot correctly decode the buffering period SEI message coded along with the 1st IDR picture.
The code can be fixed as following:
After Fix: Void TDecTop::xDecodeSEI( TComInputBitstream* bs, const NalUnitType nalUnitType ) { //HUA_FIX: the 1st buffering period SEI cannot be correctly decoded if w/o the following fix. TComSPS* sps = m_parameterSetManagerDecoder.getActiveSPS(); if(sps == NULL) { sps = m_parameterSetManagerDecoder.getPrefetchedSPS(0); } if(nalUnitType == NAL_UNIT_SUFFIX_SEI) { m_seiReader.parseSEImessage( bs, m_pcPic->getSEIs(), nalUnitType, sps, m_pDecodedSEIOutputStream ); } else { m_seiReader.parseSEImessage( bs, m_SEIs, nalUnitType, sps, m_pDecodedSEIOutputStream ); SEIMessages activeParamSets = getSeisByType(m_SEIs, SEI::ACTIVE_PARAMETER_SETS); if (activeParamSets.size()>0) { SEIActiveParameterSets *seiAps = (SEIActiveParameterSets*)(*activeParamSets.begin()); m_parameterSetManagerDecoder.applyPrefetchedPS(); assert(seiAps->activeSeqParameterSetId.size()>0); if (! m_parameterSetManagerDecoder.activateSPSWithSEI(seiAps->activeSeqParameterSetId[0] )) { printf ("Warning SPS activation with Active parameter set SEI failed"); } } } }
Before Fix: Void TDecTop::xDecodeSEI( TComInputBitstream* bs, const NalUnitType nalUnitType ) { if(nalUnitType == NAL_UNIT_SUFFIX_SEI) { m_seiReader.parseSEImessage( bs, m_pcPic->getSEIs(), nalUnitType, m_parameterSetManagerDecoder.getActiveSPS(), m_pDecodedSEIOutputStream ); } else { m_seiReader.parseSEImessage( bs, m_SEIs, nalUnitType, m_parameterSetManagerDecoder.getActiveSPS(), m_pDecodedSEIOutputStream ); SEIMessages activeParamSets = getSeisByType(m_SEIs, SEI::ACTIVE_PARAMETER_SETS); if (activeParamSets.size()>0) { SEIActiveParameterSets *seiAps = (SEIActiveParameterSets*)(*activeParamSets.begin()); m_parameterSetManagerDecoder.applyPrefetchedPS(); assert(seiAps->activeSeqParameterSetId.size()>0); if (! m_parameterSetManagerDecoder.activateSPSWithSEI(seiAps->activeSeqParameterSetId[0] )) { printf ("Warning SPS activation with Active parameter set SEI failed"); } } } }
Note that this may not be the best way to fix the issue. But it does help to avoid the decoder crash and allow it to correctly decode the bitstream. Change History (5)comment:1 Changed 10 years ago by DefaultCC Plugin
comment:2 Changed 10 years ago by ksuehringcomment:3 Changed 10 years ago by gaow02
Please refer to our embedded comments:
According to the text the SEIs refer to the currently active SPS. If there
An active parameter sets SEI message can activate the proper SPS before
[Comment]: From spec, this is a valid option, but definitely not a requirement for the proper use w/ buffering period (or picture timing) SEIs.
The fix assumes, that am SPS with sps_seq_parameter_set_id equal to 0
[Comment]: As said and identified, the reported fix may not be a good fit for the spec. But as mentioned earlier, an appropriate fix of delaying the BP and PC SEI decoding after slice header decoding, which is really fully conforming to the spec, is needed to clear this un-appropriate exiting issue, when decoding streams w/ BP and SEI messages. comment:4 Changed 10 years ago by ksuehring
comment:5 Changed 10 years ago by ksuehring
A fix has been implemented that delays parsing of all prefix SEI messages, until VPS/SPS/PPS are activated by the first VCL NAL unit of the picture.
The change has been committed in r4394 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
|
According to the text the SEIs refer to the currently active SPS. If there is no parameter set active, parsing has to be delayed (see section D.3.3 Note 1).
An active parameter sets SEI message can activate the proper SPS before parsing the buffering period (or picture timing) SEI.
The fix assumes, that am SPS with sps_seq_parameter_set_id equal to 0 exists and will be activated in the following VCL NAL unit. Although this assumption is true for all HM generated streams, there is no requirement for this in the bitstream syntax.