After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791584 - baseparse: Initial GAP handling should check for mandatory fields
baseparse: Initial GAP handling should check for mandatory fields
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 753899
Blocks: 783842
Reported: 2017-12-13 15:45 UTC by Edward Hervey
Modified: 2018-11-03 12:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Edward Hervey 2017-12-13 15:45:09 UTC
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.
Comment 1 GStreamer system administrator 2018-11-03 12:43:46 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to'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: