GNOME Bugzilla – Bug 752910
h264parse: doesn't parse nal which contains multi slice per frame
Last modified: 2018-11-03 13:39:12 UTC
H264parse doesn't parse nal when the caps have alignment with nal. Especially, h264parse couldn't parse second nal in case of multi slice.
Created attachment 308195 [details] [review] h264parse doesn't parse a frame which have alignment with nal.
Before applying patch, h264parser doesn't flush second nal of IDR as below. codecparsers_h264 gsth264parser.c:1390:gst_h264_parser_identify_nalu: Complete nal found. Off: 3, Size: 2762 h264parse gsth264parse.c:598:gst_h264_parse_process_nal:<h264parse0> processing nal of type 5 Slice IDR, size 2762 h264parse gsth264parse.c:703:gst_h264_parse_process_nal:<h264parse0> first_mb_in_slice = 0 baseparse gstbaseparse.c:2005:gst_base_parse_handle_buffer:<h264parse0> handle_frame skipped 0, flushed 2765 baseparse gstbaseparse.c:1939:gst_base_parse_prepare_frame:<h264parse0> preparing frame at offset -1 (0xffffffffffffffff) of size 3538 codecparsers_h264 gsth264parser.c:253:gst_h264_parse_nalu_header: Nal type 5, ref_idc 1 h264parse gsth264parse.c:1008:gst_h264_parse_handle_frame:<h264parse0> not a complete nal found at offset 3 baseparse gstbaseparse.c:2005:gst_base_parse_handle_buffer:<h264parse0> handle_frame skipped 0, flushed 0 After applying patch, h264parser flush buffer properly. baseparse gstbaseparse.c:1987:gst_base_parse_handle_buffer:<h264parse0> handling buffer of size 3538 with dts 99:99:99.999999999, pts 99:99:99.999999999, duration 99:99:99.999999999 h264parse gsth264parse.c:1063:gst_h264_parse_handle_frame:<h264parse0> 0xb2665599 complete nal found. Off: 3, Size: 3535 h264parse gsth264parse.c:716:gst_h264_parse_process_nal:<h264parse0> parse result 0, first MB: 54, slice type: 2 baseparse gstbaseparse.c:2005:gst_base_parse_handle_buffer:<h264parse0> handle_frame skipped 0, flushed 3538
I've seen this bug and the patch worked for me... I'm not entirely sure if it's ok to follow the draining path in that code segment. At least the debug statements should be adjusted in this case, so that we don't think that the element is draining when we debug it. Otherwise I would merge it.
Can you provide a sample stream for this? The patch looks a bit weird to me though, why don't we detect this as a complete NAL here? This at least needs some clean up of this code path, but it seems like something with the NAL parsing is wrong if we don't detect it as a complete NAL.
I've reproduced this issue with url below. http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8
> I've reproduced this issue with url below. > http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8 Any more details? Is it enough to take one of the variant streams, or does it happen when switching between bitrates? If one of the bitrates is enough, perhaps it happens with one particular fileSequence fragment, if so which?
-- 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/289.