[Gstreamer-bugs] [Bug 139926] New: - id3tag's caps cause it to be plugged more than once by spider in certain conditions

[bugzilla-daemon at widget.gnome.org]

http://bugzilla.gnome.org/show_bug.cgi?id=139926
GStreamer | gstreamer (core) | Ver: 0.8.0

           Summary: id3tag's caps cause it to be plugged more than once by
                    spider in certain conditions
           Product: GStreamer
           Version: 0.8.0
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-maint at bugzilla.gnome.org
        ReportedBy: thomas at apestaart.org
         QAContact: gstreamer-maint at bugzilla.gnome.org


since id3tag also has application/x-id3 in its src caps, possibly, sometimes
spider chooses a second id3tag as the shortest path between an already added
id3tag element and the rest of the pipeline.

Attached are two debug logs, one from my system-installed 0.8.0 GStreamer, and
one from my HEAD GStreamer.  Search the logs for "found a way to connect via" to
see where it differs.  In head.out, it plugs a second id3tag at some stage.

The reason it does this is simply due to the order in which the element
factories are traversed; the autoplug function takes the first element that can
plug between the given caps, and in my HEAD install id3tag is checked before mad.

One possible solution would be to use the autoplug_cost mechanism, which
currently is defined to give 1 always.  If id3tag would have a higher autoplug
cost than mad, it wouldn't be selected in preference to mad.

An alternative would be removing application/x-id3 from the src caps, but that's
probably bound to break other stuff.
Opinions ?

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the QA contact for the bug, or are watching the QA contact.