modified to handle dependent slices and the case where SEI arrives before the last slice of the picture

I think that creates an issue when a decoded picture hash message arrives between two VCL NAL units of a picture.

SPS and PPS are not directly overwritten, see ParametersetManagerDecoder. They are stored in a "prefetch"-buffer and only overwrite the old parameter sets when applyPrefetchedPS() is called. This is called only with the activation of a new parameter set, which should happen in decoding, not parsing.

There exist two functions for accessing either a new parameter set (getPrefetched{VSP}PS) or an old one (get{VSP}PS).

The second patch should handle the case of the SEI showing up between two slices. Regarding the operation of the ParametersetManagerDecoder, I think current HM still ends up replacing the PPS/SPS before loop filtering when a parameter activation SEI message shows up.

comments out SEI parameter sets

I suppose a simpler fix is to just have HM ignore parameter activation SEIs, since SEIs are ignorable. Patch that does this is attached, and also solves the issue I was seeing.

Unfortunately for a stream that contains buffering and timing SEI the startup won't work when ignoring the SEI (i.e. an SPS need to be active before buffering and timing can be parsed). Maybe we can ignore the SEI in the middle of the bitstream.

That would be ok, it is still simpler than the second patch that initiates loop filtering after the picture completes, although I do think that seems more "correct".

I would like to test lf_fix_2. Filtering at the end of the picture seems to be helpful to also avoid reading the slice header twice. Unfortunately the patch does not apply to the current HM-10.0-dev branch. Could you please update it?

loop filter patch updated for HM10.0-dev

Attached

ok the patch needs a small tweak, otherwise SEIs of skipped leading pictures will try to get applied to the previously decoded IRAP.

In TDecTop::xDecodeSlice, add the m_digestCanBeChecked assignments:

  if (isRandomAccessSkipPicture(iSkipFrame, iPOCLastDisplay))
  {
    m_digestCanBeChecked = false;
    return false;
  }
  // Skip TFD pictures associated with BLA/BLANT pictures
  if (isSkipPictureForBLA(iPOCLastDisplay))
  {
    m_digestCanBeChecked = false;
    return false;
  }

The activation SEI can activate VPS, SPS, but not PPS. VPS and PPS do not contain SAO and DBF related parameters. So I'm wondering why activation SEI will make it wrong?

Replying to conrad.ho:

The activation SEI can activate VPS, SPS, but not PPS. VPS and PPS do not contain SAO and DBF related parameters. So I'm wondering why activation SEI will make it wrong?

The real problem is that loop filter code gets the pic height & width from the newly activated SPS, which isn't parsed yet (all the values are garbage).

Sorry, my previous statement is incorrect. The slice's pointer to the old SPS refers to de-allocated memory by the time the loop filter runs.

The patch has been applied in r3497.

There are alternative ways to solve the issue, but they might require more work.

Reopening. The patch was reverted in trunk r3508 because it breaks decoding of conformance streams SLIST_B and SLIST_D

A severe effect is that the output picture is wrong from the beginning while the MD5 check fails only much later. We should make sure this does not happen.

Perhaps each slice can simply allocate and keep a duplicate copy of its SPS/PPS, and deallocate in the destructor.

Fixed in r4219 by placing a constant instance of the SPS and PPS within
TComPicSym. The SPS/PPS pointers within a slice point to the instance
within the TComPicSym. The decoder will abort if the active PPS/SPS
changes whilst decoding a picture.

Batch modify of recently closed tickets to set milestone to HM-16.3.