Opened 4 years ago
Closed 3 years ago
#1446 closed defect (fixed)
Picture header should be in its own NALU
| Reported by: | fbossen | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | Conformance | Version: | |
| Keywords: | Cc: | ksuehring, fbossen, jvet@… |
Description
The semantics of sh_picture_header_in_slice_header_flag state that:
When any of the following conditions is true, the value of sh_picture_header_in_slice_header_flag shall be equal to 0:
- The value of sps_subpic_info_present_flag is equal to 1.
- The value of pps_rect_slice_flag is equal to 0.
- The value of pps_rpl_info_in_ph_flag, pps_dbf_info_in_ph_flag, pps_sao_info_in_ph_flag, pps_alf_info_in_ph_flag, pps_wp_info_in_ph_flag, or pps_qp_delta_info_in_ph_flag is equal to 1.
SLICES_A_HUAWEI_2 appears to not abide by this restriction as sh_picture_header_in_slice_header_flag is equal to 1 when pps_rect_slice_flag is equal to 0 (2nd IRAP frame).
Change history (2)
comment:1 Changed 4 years ago by biaowang
comment:2 Changed 3 years ago by fbossen
- Resolution set to fixed
- Status changed from new to closed
Fixed in SLICES_A_HUAWEI_3
Note: See TracTickets for help on using tickets.
Thanks for reporting this issue, and it is confirmed.
This bitstream exercises six layouts.
Each layout last for 5 frames and it is the second layout (the entire frame has only one raster slice) causes this issue in the SLICES_A_HUAWEI_2 package.
I have removed this layout in the newly generated bitstream SLICES_A_HUAWEI_3.bit using VTM-12.3.