[gstreamer-bugs] [Bug 357404] New: [playbin] Linking can fail silently

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=357404

GStreamer | gst-plugins-base | Ver: HEAD CVS

           Summary: [playbin] Linking can fail silently
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: mail at renestadler.de
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Playbin does not check if the linking to the app supplied sinks is successful. 
See uses of gst_element_link_pads in
gst-plugins-base/gst/playback/gstplaybin.c.
The problem with this is that it blindly assumes that the sink pad is named
"sink".  This is probably fine for the converters it creates, but not for the
user-supplied sinks.  I'm under the impression that element and pad names are
mainly for easing debugging and documentation, they do not matter to the
framework.

Solution: Check link success at least with an assertion or throw an error which
is even better.  Link elements using gst_element_link, which does not depend on
secret pad naming conventions if I'm correctly informed.  Should the current
naming requirement be kept, mention it in the docs.

I just spent hours of wading through debug output to find out why an app would
freeze over after a change so trivial I couldn't remember it or tested after
including it (a simple pad name change!).  That's why this bug is such a
bummer, you end up with a pipeline that never gets out of preroll without any
error whatsoever.


-- 
Configure bugmail: http://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.