Skip to content

Technical notes on using gstreamer as the dataflow engine

sofian edited this page Jan 28, 2013 · 3 revisions

Message sent to the gstreamer-devel mailing list (still awaiting response)

Types: GStreamer supports any kind of data (they just need to be qualified by a string, basically)

Possible caveats:

  • GStreamer doesn't support cyclical graphs
    • There seems to be ways to circumvent that eg. this discusssion suggests to use a pad probe to reinject data
  • Could be cumbersome if we need to define a GStreamer plugin for everything, although I believe we can create GstElements "on-the-fly"

Jan. 28th 2013 conversation about link/unlink callbacks:

* Now talking on #gstreamer
tats -  hi. when i call gst_pad_add_probe (src, (GstPadProbeType)GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM, callback, data, NULL); to install a blocking probe on a pad, is the pad blocked right after the call to the function or is it blocked when the callback is called (or both)?
tats -  also, it feels like the callback is not called when the pipeline is not playing (which is not indicated in the documentation)
tats -  finally, is there a "default" probe id that is returned by gst_pad_add_probe when the probe adding was not successful?
wtay -  tats, it's blocked before and after the call of the callback
wtay -  tats, the callback is only called when there is dataflow, which could not be in paused
wtay -  tats, 0 is an invalid probe id
tats -  wtay, so for instance, if the pipeline is playing and i want to unlink a pad, i can call gst_pad_add_probe(...) with no callback, and right after i can safely call gst_pad_unlink() on the pad?
wtay -  no
wtay -  you can only unlink after the callback is called
tats -  ok. so if i want to unlink, i need to make a special case for when the pipeline is in the playing state (in which case i need to unlink inside the callback). ie. something like this: http://pastebin.com/qQAVLBYH
tats -  the problem i see is that if between the check of the state and the gst_add_probe, the pipeline changes state, it will not do what i want.
wtay -  tats, usually not, you just unlink when you get the callback
wtay -  tats, unlinking in paused has no effect anyway
tats -  wtay, ??? no effect? can I link to a new pad if I didn't unlink before?
wtay -  no
tats -  wtay, so, then it does have an effect.
tats -  i want to make two methods: one for connecting and one for disconnecting pads, safely, under any circumstances (wether the pipeline is playing, paused, prerolling, etc). is it possible to do that?
wtay -  yes
tats -  ok. well my problem right now is that line 18 seems to hang indefinitely. i'd like to guarantee that when i get out of my safeDisconnect() method, that the pads are disconnected.
tats -  (ie. unlinked)
wtay -  tats, it is impossible
tats -  why?
wtay -  because in paused the pad might be actively pushing some data to the peer and then you can't unlink
tats -  in paused? hmmm. i did not expect that. i didn't know data was still being pushed in pause. so is there any way to know when the pad has finished pushing its data while in the paused state so that i can unlink?
wtay -  you can but that's not going to help because it might not finish pushing
wtay -  if you want to unlink safely, add a blocking probe (or idle probe) and unlink in the callback
wtay -  that's what we do to switch visualizations in paused and playing
tats -  wtay, but will the callback be called in the paused state? it seems to be only called in the playing state
wtay -  tats, it may or may not be called in paused
wtay -  tats, if it's not called, it's not safe to unlink
wtay -  kalem, what doesn't change?
tats -  ok. i understand. but will the callback be called when it becomes safe to unlink? otherwise, I have no way to know whether it was or wasn't safe to unlink.
tats -  or is it that gst_pad_add_probe() will return 0 if it's not safe to unlink?
wtay -  tats, yes, it will only be called when it's safe, like when you go back to playing
tats -  ok. i see. well, this is kind of bad for me then. makes the whole thing harder to manage, because if i want to freely connect/disconnect/reconnect i need to do everything in callbacks.
wtay -  tats, yes

Clone this wiki locally