mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-25 03:01:03 +00:00
Code Issues 1 Projects Releases Wiki Activity

IRC conversation with jdahlin about some aspects of gstreamer+python

Browse source 
Original commit message from CVS:
IRC conversation with jdahlin about some aspects of gstreamer+python
This commit is contained in:
Jan Schmidt 2005-04-25 03:54:28 +00:00
parent 418ac69651
commit c6235da678
1 changed files with 134 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

134
docs/random/thaytan/python-elements.txt Normal file
View file

@ -0,0 +1,134 @@
Feb 22 01:45:36 <thaytan> jdahlin: can I access GstXOverlay and friends from pygst?
Feb 22 01:45:43 <jdahlin> thaytan: indeed you can!
Feb 22 01:46:05 <jdahlin> thaytan: do not forget to import gst.interfaces
Feb 22 01:46:20 <thaytan> wheeeeee!
Feb 22 01:46:28 * thaytan hi5s jdahlin
Feb 22 01:46:32 <jdahlin> after that it's all magic
Feb 22 01:46:46 <thaytan> Company and I were discussing yesterday having a gst python element
Feb 22 01:46:57 <jdahlin> that'd be cool
Feb 22 01:47:11 <jdahlin> or just <any language except c>
Feb 22 01:47:23 <thaytan> that might do something like: instantiate a python interpreter, load python modules that implement gstreamer elements from a path location and register
them
Feb 22 01:47:39 <thaytan> then for each instance of each element, start a new python interpreter instance to execute it
Feb 22 01:47:48 <jdahlin> thaytan: yes, but we need to have a loader api first
Feb 22 01:47:50 <thaytan> does that sound like the right approach?
Feb 22 01:48:02 <jdahlin> yes, that's what I had in mind too
Feb 22 01:48:17 <jdahlin> but the code should probably be separated from the rest of the core
Feb 22 01:48:18 <thaytan> loader api?
Feb 22 01:48:29 <thaytan> oh, I was thinking in gst-plugins
Feb 22 01:48:34 <jdahlin> so, we can have the python plugin loader in a separate .so
Feb 22 01:48:42 <thaytan> but I guess gst-python could install it
Feb 22 01:48:52 <thaytan> since you have to have gst-python to run such elements anyway
Feb 22 01:49:00 <jdahlin> nope
Feb 22 01:49:10 <jdahlin> or hmm
Feb 22 01:49:24 <thaytan> the python elements need to be able to call gstreamer functions
Feb 22 01:49:30 <thaytan> hence, they need the wrappers
Feb 22 01:49:31 <jdahlin> yeah, most likely a python plugin will use the gstreamer api
Feb 22 01:49:51 <jdahlin> so a GTypeModule loader would be fine for me
Feb 22 01:50:06 <jdahlin> similar to what nautilus does
Feb 22 01:51:43 <thaytan> erm, hrmn
Feb 22 01:51:48 <thaytan> I don't know what that implies
Feb 22 01:52:13 <jdahlin> so, we need to define a simple api, for a plugin loader
Feb 22 01:52:29 <thaytan> python api, you mean?
Feb 22 01:52:31 <jdahlin> and then on startup, we look in $libdir/gstreamer-x.y/loaders/ for *.so
Feb 22 01:52:46 <thaytan> oh, I see
Feb 22 01:52:52 <jdahlin> one for python, and maybe move the current one to be a dll too
Feb 22 01:53:12 <jdahlin> it probably has disadvantages to move, so I'm not making that decision
Feb 22 01:53:40 <thaytan> well, afaics, they can just be normal gst plugins that in the plugin_init, they instantiate their language binding, load the available elements and get
them to register themselves
Feb 22 01:53:45 <jdahlin> and one for every language which wants to be able to write elements
Feb 22 01:54:09 <jdahlin> perhaps, I'm not sure how plugins work, but maybe it's possible
Feb 22 01:54:31 <thaytan> we want to get them in the registry with a factory function that knows how to instantiate the interpreter and create an instance of the element to run in it
Feb 22 01:54:50 <thaytan> and some way to shut down that instance when the element disappears
Feb 22 01:55:18 <jdahlin> would be a nice idea to only start the python interpretor on demand
Feb 22 01:55:24 <thaytan> for python, do we need a separate interpreter instance for every element?
Feb 22 01:55:35 <thaytan> so they can run properly in separate threads?
Feb 22 01:55:56 <jdahlin> no, that is not supported
Feb 22 01:56:02 <jdahlin> all elements are going to run in the same interpretor
Feb 22 01:56:17 <jdahlin> interpreter!
Feb 22 01:56:18 <thaytan> that might cause deadlocks?
Feb 22 01:56:35 <thaytan> my understanding is that the python interpreter is single-threaded only
Feb 22 01:56:47 <jdahlin> no, it can be multi-threaded
Feb 22 01:56:59 <jdahlin> but we'll probably have interesting issues
Feb 22 01:57:16 <thaytan> so nautilus already does something like this, you say?
Feb 22 01:57:20 <jdahlin> actually it's not supported to have multiple python interpreters in the same process
Feb 22 01:57:33 <jdahlin> yes, it reuses the interpreter state for all plugins/modules
Feb 22 01:57:55 <thaytan> we should check that out
Feb 22 01:58:08 * jdahlin wrote that code
Feb 22 01:58:22 <jdahlin> but it's mainly a proof of concept
Feb 22 01:58:47 <thaytan> oh, heh
Feb 22 01:59:02 <thaytan> I guess you already know the gist of it then
Feb 22 01:59:23 <jdahlin> actually, when it comes to threads I usually start crying
Feb 22 01:59:32 <thaytan> yah, but you're a sensitive man
Feb 22 01:59:44 <jdahlin> yes
Feb 22 01:59:51 <thaytan> I heard you cried over the bit in terminator 2 where arnie goes into the molten metal
Feb 22 01:59:53 <jdahlin> we need real men like wtay to help us
Feb 22 02:00:14 <jdahlin> yes, that is such a sad moment
Feb 22 02:00:31 <thaytan> *giggle*
Feb 22 02:00:48 <thaytan> and I'm all like 'hah! take that Eddie Furlong!'
Feb 22 02:02:03 <jdahlin> actually I can't remember, since it was a long time ago I saw the movie the first time
Feb 22 02:23:17 <thaytan> jdahlin: so python-nautilus seems to bail out if python is already instantiated?
Feb 22 02:23:33 <jdahlin> thaytan: perhaps, proof of concept :)
Feb 22 02:37:41 <thaytan> jdahlin: how do I physically register a python-implemented class from C?
Feb 22 02:38:11 <thaytan> sorry, I mean how do I get a GType that creates a python object?
Feb 22 02:39:20 <thaytan> or alternatively, load a python file in the interpreter and give it a GstPlugin * so it can call gst.element_register for each element it implements
Feb 22 02:41:33 <jdahlin> thaytan: you'll register the class in python (gobject.type_register)
Feb 22 02:41:54 <jdahlin> which will create a PyGType and a GType
Feb 22 02:42:16 <thaytan> ok, so we need the second method
Feb 22 02:42:39 <thaytan> the .py file implements a plugin_init function for us to pass a GstPlugin instance to
Feb 22 02:43:31 <thaytan> thomasvs: woah, how far behind am I?
Feb 22 02:43:43 <thaytan> thomasvs: in my stream, Uraeus just said the 'basically' stuff
Feb 22 02:47:49 <jdahlin> thaytan: no, it's fine to register the plugin in python, then we can just introspect and get a list of all classes subclassed from say gst.Element
Feb 22 02:50:02 <thaytan> jdahlin: I'm wondering how it works: I write a C plugin that instantiates a python interpreter in the plugin_init function, and then iterates a directory of .py files as python-nautilus does
Feb 22 02:50:47 <thaytan> it finds the plugin_init function inside each .py file, and needs to call it, passing a python-wrapper something or other for the GstPlugin * it was given
Feb 22 02:51:11 <thaytan> how do I go from an existing GstPlugin * to something I can pass to python?
Feb 22 02:52:33 <thaytan> is that what nautilus_python_object_get_type is doing?
Feb 22 02:52:59 <thaytan> ds: so you just have to carefully avoid symbol collisions between 0.3 and 0.4?
Feb 22 02:53:38 <jdahlin> thaytan: no, there is no plugin_init, that's the global part of the module in python
Feb 22 02:55:05 <jdahlin> thaytan: the GstPlugin would in this case never be seen from the python code; you would just have global variables, __plugin__, __version__ etc
Feb 22 04:05:23 <jdahlin> thaytan: no, the registration code is called from python
Feb 22 04:06:02 <thaytan> I'm trying to figure out a simpler problem
Feb 22 04:06:17 <thaytan> well, one earlier in the chain - how to allow GstElements that are implemented in python
Feb 22 04:06:40 <jdahlin> it's the same problem!
Feb 22 04:06:42 <thaytan> at the moment it seems I can't derive a GstElement in python and have it work?
Feb 22 04:06:55 <jdahlin> well, sort of
Feb 22 04:07:02 <-- caro has quit ("using sirc version 2.211+KSIRC/1.3.10")
Feb 22 04:07:08 <jdahlin> that needs some work, without doubts
Feb 22 04:07:13 <thaytan> yes, sort of - creating a derived Gstelement is one problem
Feb 22 04:07:18 <thaytan> registering it is another
Feb 22 04:07:41 <thaytan> I was just reading through pygtk and trying to understand
Feb 22 04:07:48 <jdahlin> I did implement something that I used as a filesrc
Feb 22 04:07:54 <jdahlin> in pure python at some point
Feb 22 04:08:03 <thaytan> how do you specify, say, the state_change handler?
Feb 22 04:08:05 <jdahlin> but most of the functions in GstElement and GstPad are not implemented
Feb 22 04:08:13 <jdahlin> I didn't
Feb 22 04:08:14 <jdahlin> :D
Feb 22 04:08:22 <thaytan> aha :)
Feb 22 04:08:37 <jdahlin> thaytan: examples/gst/filesrc.py
Feb 22 04:08:46 <thaytan> I'm trying to figure out how GObject class function pointers get mapped to Python
Feb 22 04:08:48 <jdahlin> just a get_function on the source bad
Feb 22 04:08:52 <jdahlin> pad
Feb 22 04:09:22 <thaytan> gst_element_set_state becomes gst.Element.set_state, which is clear enough
Feb 22 04:09:46 <thaytan> but what happens if set_state is also a class method you want to override?
Feb 22 04:10:18 <jdahlin> in pygtk 2.5.x and higher you can do that
Feb 22 04:10:27 <jdahlin> It'll be prefixed by do_
Feb 22 04:10:52 <thaytan> and there's a gst_element_do_set_state() and a 'set_state' function ptr?
Feb 22 04:10:58 <thaytan> and _if_ theres...
Feb 22 04:11:23 <jdahlin> tough luck.
Feb 22 04:11:48 <jdahlin> well, seriously
Feb 22 04:11:55 <jdahlin> then do_set_state will be renamed in the python bindings.
Feb 22 04:19:15 <thaytan> jdahlin: so ok, our step 1 is to enhance pygst to support all the class methods
Feb 22 04:22:30 <jdahlin> thaytan: that is easy, we need to update the defs file and add virtuals methods. then we need to require pygtk 2.6.0 when it's out (in a few weeks, maximum)
Feb 22 04:31:05 <thaytan> jdahlin: what does a virtual defn look like in a .defs file?
Feb 22 04:31:20 <jdahlin> thaytan: not sure, look in pygtk cvs head
Feb 22 04:31:24 * jdahlin didn't write that code
Feb 22 04:31:34 <thaytan> I've got 2.5.3 - not recent enough?
Feb 22 04:31:41 <jdahlin> yeah, it is
Feb 22 04:34:38 <thaytan> jdahlin: aha found it. seems simple enough
Feb 22 04:34:40 <thaytan> (define-virtual pressed
Feb 22 04:34:40 <thaytan> (of-object "GtkButton")
Feb 22 04:34:40 <thaytan> (return-type "none")
Feb 22 04:34:40 <thaytan> )