[Bug 767499] New: Spatial Resolution Change Causes Playback Freeze

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=767499

            Bug ID: 767499
           Summary: Spatial Resolution Change Causes Playback Freeze
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-omx
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: samuelh at rd.bbc.co.uk
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 329578
  --> https://bugzilla.gnome.org/attachment.cgi?id=329578&action=edit
xz compressed log

ftp://ftp.bbc.co.uk/incoming/bbb-avc3-rep2-rep4.mp4


I've got an issue with decoding DASH content on a Raspberry Pi using git latest
GStreamer. When something in a running stream causes a spatial resolution
change (e.g. changing a DASH representation), if the spatial resolution change
is the only change then the stream will freeze. If the change involves a
spatial resolution change along with another change in the stream such as H.264
level or profile, then the video doesn't freeze and the change works.

The stream decodes correctly on two other platforms that I have which are both
built from the same source code but do not use gst-omx. Below is the exact
versions of what I'm running, in case it helps:

* Buildroot 2016.05, building Linux kernel 4.4.8, Raspberry Pi firmware version
cc6d7bf8
* GStreamer latest (git 8c7da1d4)
* gst-plugins-base (git 8b8708f9)
* gst-plugins-good (git b4a4fa19)
* gst-plugins-bad (git 3107f5df)
* gst-libav (git 1a4c54a6)
* gst-omx (git 94789f19)

When the failure happens, no errors or warnings are printed to the console by
any element. As far as I've been able to deduce so far, when a representation
change happens which changes more than just the spatial resolution it triggers
gst_omx_video_dec_set_format() with the new caps for the stream. However, if
the change is only the spatial resolution, then this call never happens and the
stream freezes.

Looking at the caps, the spatial resolution on the input caps of the omx
decoder seems to be set to the maximum resolution of all representations in a
given adaptation set all the way through and never changes. The output caps
then differ according to what it's supposed to be playing.

I've managed to create a short clip which recreates this issue outside of DASH,
taken from a Big Buck Bunny DASH stream. The stream is effectively one file
containing an initialisation segment, two 4 second segments from the first
representation and a two 4 second segments from the second representation,
concatenated together. The spatial resolution changes from 704x396p50 to
960x540p50. Both representations use an avc3 sample entry format, have a H.264
level of 3.1 and both use high profile. You can download the clip from here:
ftp://ftp.bbc.co.uk/incoming/bbb-avc3-rep2-rep4.mp4

I've also attached a log made with GST_DEBUG="videodecoder:5,omx*:5".

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.