[Bug 791584] New: baseparse: Initial GAP handling should check for mandatory fields

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Dec 13 15:45:09 UTC 2017


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

            Bug ID: 791584
           Summary: baseparse: Initial GAP handling should check for
                    mandatory fields
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: bilboed at bilboed.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: bilboed at bilboed.com, hoonh83.lee at gmail.com,
                    nicolas at ndufresne.ca, olivier.crete at ocrete.ca,
                    slomo at coaxion.net, t.i.m at zen.co.uk
        Depends on: 753899
            Blocks: 783842
     GNOME version: ---

There is no way for subclasses to tell the parent class that it doesn't have
enough information to negotiate to at least a compatible format.

For example:
* mpegaudioparse receives "audio/mpeg, mpegversion=1" (without any other
fields)
* A gap event comes in
* the base class negotiates to "audio/mpeg, mpegversion=1, layer=1,
mpegaudioversion=1, rate=8000, channels=1, parsed=true"
* the caps event get pushed downstream and a decoder gets selected for MP1 (say
avdec_mp1float)
* eventually data comes into mpegaudioparse and it negotiates to the *actual*
format (mpegaudioversion=3, i.e. mp3)
* the decoder fails to negotiate

While we do want to not delay gap events in parsers, we should only allow this
to happen if we do have enough information from upstream caps to negotiate to
something which will later be compatible with the actual data stream.

In this case, mpegaudioparse should *not* push caps event if it hasn't at least
got a clue as to which mpegaudioversion the stream corresponds to.

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


More information about the gstreamer-bugs mailing list