JVET-R0041: Picture types related constraints
1 unresolved thread
1 unresolved thread
Merge request reports
Activity
- Resolved by Karsten Suehring
- Resolved by Karsten Suehring
- Resolved by Karsten Suehring
- Resolved by Karsten Suehring
added 6 commits
-
5691abee...c981524c - 2 commits from branch
jvet:master
- c030dc11 - JVET-R0041: Picture types related constraints
- 015604e1 - fix linux compiling issue
- 2b5ad5a2 - rebase to master
- 1f2168d2 - cleanup
Toggle commit list-
5691abee...c981524c - 2 commits from branch
mentioned in commit befdfd07
1218 1316 } 1219 1317 } 1220 1318 } 1319 #endif 1221 1320 1222 // When a picture is a leading picture, it shall precede, in decoding order, 1223 // all trailing pictures that are associated with the same IRAP picture. 1321 #if JVET_R0041 1322 if (pcSlice->getPicHeader()->getPicOutputFlag() == 1 && !this->getPicHeader()->getNoOutputBeforeRecoveryFlag() && pcPic->layerId == this->m_nuhLayerId) 1323 { 1324 if (this->getPOC() == this->getPicHeader()->getRecoveryPocCnt() + this->getPrevGDRInSameLayerPOC()) On a GDR picture, this check add the previous GDR poc with the new recovery_poc_cnt. The compliance check is therefore wrong on these picture.
Furthermore, it is called even if there is no GDR in the stream. A RADL with poc -1 after a CRA with poc 0 will be signaled as not compliant, as all is initialized to 0!
Thanks for pointing out this issue. I created MR !1687 (merged) trying to fix this bug. Would you please have a try?
Edited by Zhipin Deng
mentioned in merge request !1687 (merged)
mentioned in commit 4885c797
Please register or sign in to reply