[gstreamer-bugs] [Bug 563828] [decodebin2] Complains about loops in the graph on MXF files containing DV

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=563828

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




------- Comment #9 from Sebastian Dröge  2008-12-20 18:02 UTC -------
Hm, there's still a problem.

We can't just check on the factories as the factories only contain the static
pad templates and we probably don't want to instanciate all elements.

The other solution would be to move the "is_demuxer_element (src)" check and
gst_decode_group_control_demuxer_pad() call between 2.4 and 2.5. The check
should be extended to "is_demuxer_element (src) && !is_demuxer_element
(element)" and then it works just fine for my testcase.
mxfd10.c
Now there's only the problem, what to do if linking or set_state() on the
element fails later. We might need to destroy a decode group (as it was created
just for the current element that didn't work) and we have to remove the
created requestpad on the multiqueue. And of course reset pad/src to the old
values.

Currently I don't see an easy way to accomplish that :)


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=563828.