[Bug 732203] New: h264parse: improve handling of byte-stream/au format

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=732203
  GStreamer | gst-plugins-bad | git

           Summary: h264parse: improve handling of byte-stream/au format
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: gb.devel at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


If stream-format=byte-stream and alignment=au, i.e. when this is not avcC
format (avc/au), h264parse will skip NAL unit if we did not receive an SPS/PPS
pair yet. The issue is that this not only drops the unhandled NAL unit (e.g.
SPS-Ext or SEI message with buffering_period()), but also *all* previous NALs.
Subsequently, downstream doesn't know about SPS, and would fail to decode the
stream.

There are multiple ways to fix this. However, since we are about to release
1.4-RC, I am going to explore the following solution: always call
gst_h264_parse_process_nal() in _handle_frame, regardless of the current NAL
unit and make that function perform some checking (e.g. got SPS, got PPS,
etc.), and skip the current NAL in case of failure then.

This would make it possible to (i) handle SEI NAL with buffering_period()
message inserted between an SPS and PPS, (ii) handle valid SPS-Ext NAL unit
that follow the SPS, and fix additional bugs.

The most correct way to fix this, IMHO, is to enable transform = TRUE in that
case and accumulate the valid NAL units to the GstAdapter, instead to just
starting over. With the additional condition that, if we need to genuinely skip
a NAL unit (e.g. broken NAL), and if no slice NAL was received so far, then,
don't drop the previous NALs, emit them right away. That could allow some form
of recovery to downstream. Most importantly, we keep receiving SPS and PPS.

Both approaches require the same amount of time for implementation. However,
approach (2) is more risky and requires additional regression testing. That's
why I would focus on approach (1), which I believe should fit our immediate
purposes.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.