GNOME Bugzilla – Bug 340420
using bins in gnlsource doesn't work
Last modified: 2006-05-08 14:25:42 UTC
Please describe the problem: adding a bin with a ghosted src pad into gnlsource doesn't work Steps to reproduce: 1. add a bin with a ghosted src pad into a gnlsource element 2. use the gnlsource element 3. see it not work Actual results: the src pad will not be linked, but an GST_PAD_LINK_WRONG_HIERARCHY error is given instead Expected results: the gnlsource element should be used as usual Does this happen every time? yes Other information:
Created attachment 64673 [details] a sample code demonstrating the problem run this code with --gst-debug-level=3, and see the following error output: INFO (0x80510a8 - 0:00:00.177449000) ^[[00;01;37;41m GST_PADS^[[00m(^[[332m27715^[[00m) ^[[00;01;37;41mgstpad.c(1700):gst_pad_link_prepare:^[[00m pads have wrong hierarchy compile it with -DUSE_TEST_SRC, and see the code work the only difference between the two compilation modes is that in the latter, just a test source is used. whereas in the previous case, the very same test source is put into a bin... (the test code is based on the tests/check/simple.c code found in gnonlin)
The problem is because probes and pad blocking don't work on ghostpads of ghostpads, which is used in gnlsource. Marking this as a duplicate of relevant core bug : #341029 *** This bug has been marked as a duplicate of 341029 ***
are you sure? I mean, it's not a blocking problem, one can't even link pads, let alone block them. or how would the hierarchy error response indicate blocking issues?