GNOME Bugzilla – Bug 740748
h265parse: Fix the logic for constructing a complete AU
Last modified: 2018-11-03 13:28:57 UTC
In h265parse, it doesn't consider all nal_unit_type about VCL(Video Coding Layer) to construct a complete AU. It can resolve using following patch. diff --git a/gst/videoparsers/gsth265parse.c b/gst/videoparsers/gsth265parse.c index 2d7b997..4a36e3b 100644 --- a/gst/videoparsers/gsth265parse.c +++ b/gst/videoparsers/gsth265parse.c @@ -693,10 +693,8 @@ gst_h265_parse_collect_nal (GstH265Parse * h265parse, const GST_LOG_OBJECT (h265parse, "nal type: %d %s", nal_type, _nal_name (nal_type)) /* coded slice NAL starts a picture, * i.e. other types become aggregated in front of it */ - h265parse->picture_start |= ((nal_type >= GST_H265_NAL_SLICE_TRAIL_N - && nal_type <= GST_H265_NAL_SLICE_TRAIL_R) - || (nal_type >= GST_H265_NAL_SLICE_BLA_W_LP - && nal_type <= RESERVED_IRAP_NAL_TYPE_MAX)); + h265parse->picture_start |= (nal_type >= GST_H265_NAL_SLICE_TRAIL_N + && nal_type <= RESERVED_IRAP_NAL_TYPE_MAX); /* consider a coded slices (IRAP or not) to start a picture, * (so ending the previous one) if first_slice_segment_in_pic_flag == 1*/ @@ -711,10 +709,8 @@ gst_h265_parse_collect_nal (GstH265Parse * h265parse, const /* Any VCL Nal unit with first_slice_segment_in_pic_flag == 1 considered star complete |= h265parse->picture_start - && (((nal_type >= GST_H265_NAL_SLICE_TRAIL_N - && nal_type <= GST_H265_NAL_SLICE_TRAIL_R) - || (nal_type >= GST_H265_NAL_SLICE_BLA_W_LP - && nal_type <= RESERVED_IRAP_NAL_TYPE_MAX)) + && ((nal_type >= GST_H265_NAL_SLICE_TRAIL_N + && nal_type <= RESERVED_IRAP_NAL_TYPE_MAX) && (nnalu.data[nnalu.offset + 2] & 0x80)); GST_LOG_OBJECT (h265parse, "au complete: %d", complete);
Thanks for your patch, but can you attach it to this bug in "git format-patch" format?
ping ?
Created attachment 299879 [details] [review] Patch to consider all VLC slices
Sample file: http://www.elecard.com/assets/files/other/clips/bbb_720p_c.ts This clearly breaks the decoding of the linked file. But the code seems to intentionally only check some of the slices - can someone explain why? Maybe there is something else to consider? Possibly related: With sample file the parser outputs thousands of FIXME messages: Implement timestamp/duration interpolation based on SEI message If no one is working on this, maybe the priority could be reduced?
Do you have suffix SEI ? or some reserved SUFFIX included in the check ? It seems like a common mistake with H265, specially for those coming from H264 background.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/194.