GNOME Bugzilla – Bug 797281
h264parse/h265parse: Multi-slices and NAL alignments fixes
Last modified: 2018-11-03 14:36:12 UTC
I've been working on multi slices H264/H265 streaming and encounter several issues with h264parse/h265parse. This encoding method is used to reduce the latency. When used, we want the decoder to start decoding the frame as soon as a slice is received rather then when a complete image was found. My patchset is not full ready yet, specially that I need to add unit test for each of the aspect corrected. If we merge the base class for these, we'll probably be able to reduce this patchset size, though we need to rewrite it at the same time. Overall, I've been addressing issues like: - Input alignment isn't used to reduce parsing latency - Timestamps/Duration issues - Marker flags not being used/transferred - Missing AUD insertion (h265parse) - First NAL is pushed because we have complete caps (need work still) - Bug in H265parse caused by SUFFIX SEI not being treaded as such https://gitlab.collabora.com/nicolas/gst-plugins-bad/commits/h26xparse-fixes
There is also one aspect that I might need to rework (and isn't fixed on h265 yet). Whenever we know the duration (framerate in caps, or vui sei), we set the buffer duration. Though in NAL alignment, it ends up like: PPS: 0 SPS: 0 SLICE1: 16ms SLICE2: 0ms This way the sum of the durations of all NALs implicated in an AU represent a frame duration. This is to me a little ODD, I was expecting to set time NONE on PPS/SPS. Then set a valid duration on one of the slices. H265 currently sets the same duration on all the slices and headers. This could all equally be valid as long as we agree on one way.
-- 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/800.