[gst-devel] Pad block/element switch does not work properly

René Stadler mail at renestadler.de
Sun Nov 12 04:12:54 CET 2006


Am Samstag, den 11.11.2006, 20:38 +0100 schrieb Fredrik Persson:
> The procedure described in docs/design/pad-block.txt does not work
> properly for switching a src element.
> 
> Please try my example.
> 
> This is the python script:
> 
> http://pastebin.com/821082
> 
> It comes along with a very simple GUI:
> 
> http://pastebin.com/821084
> 

Send such things as attachments next time.

> Just put those two files in the same directory (naming then
> padblocktest.py and padblocktest.glade) and run 
> 
> python padblocktest.py
> 
> I'm expecting, here, to see that one videotestsrc element shall be
> replaced with another videotestsrc element when the user clicks the
> "change" button in the GUI. This does not happen. Instead, the first
> videotestsrc gives me an error message:

I haven't tested this, but from looking at the code, I'm expecting this
to give a warning about "trying to dispose an element that is not in the
NULL state" (see below).  You also don't set the replacement source to
the PLAYING state, so I don't expect this to show anything after the
replace happens anyways.

> 
> streaming task paused, reason not-linked (-1)
> 
> And this message is given AFTER I've unblocked the xvimagesink srcpad.
> At that point, the first videotestsrc should be gone. It should not be
> alive at all.
> 

The first source is alive and kicking.  The warning I mention to expect
above is not given because the old source is not even disposed.  You
define the src variable in the global scope, but your assignment in the
callback, which is supposed to replace the old object only affects the
local scope.  You should rename the "src" argument of the callback
function to "old_src", or leave it out completely.  I assume you added
it to avoid getting an UnboundLocalError.  However, the correct solution
is to add a "global src" to the beginning of the function.

I find Python's scoping rules to be very intuitive these days, with the
exception of global variables.  They are still dangerous, you need to be
careful.

> Any suggestions? Should I file a bug?
> 
> Regards,
> 
> Fredrik Persson
> 

Regards,
  René Stadler





More information about the gstreamer-devel mailing list