The SoC Coding Period Starts Off

The Last Few Days

Defining pipelines for test sources

I have been revamping the code. The major change was the introduction of a class structure and subsequent code to support pipelines for testing. Any pipeline can be derived using the base pipeline. It supports some basic functionalities. Of course, newer functionalities will be added into the classes which are derived from this class. I made a class for testing a video source which uses a derived and modified version of this base pipeline. This kind of a video source allows simulating a test video source without the overhead of creating a separate shell process.

Looking into the Gio Modules

I have been also trying to control the gst-switch-srv through the dbus. GDbus or rather Gio is very much capable of handling the situation. It has low-level bindings. DBus on the other hand uses the libdbus library for its communication. Thus, it can be said that GDbus is far more extensible than DBus. However the problem with GDbus is that it lacks a documentation especially for the python modules. I found some good stuff at http://developer.ubuntu.com/api/ubuntu-12.10/python/Gio-2.0.html. Only problem here is that the documentation for the C functions and not for Python. I tried a bit but was only capable of calling remote methods which get information such has get_encode_port, get_audio_port etc. However calling methods where a parameter had to be specified crashed the server again and again even after repeated attempts. Lack of examples and proper documentation for the Python modules was indeed a hindrance. :(

So, I decided to take a deeper look into previously tested DBus module itself thinking that I might be wrong previously in underestimating DBus. DBus has an easy structure where you can define a bus first and then use functions of the bus itself to call methods on the remote object. Gst-switch-srv uses a non-default bus address at "unix:abstract=gstswitch". Getting my hands dirty I found out that the DBus module internally uses a Connection class for the actual connection to the dbus. This Connection was ultimately derived by the Bus class. The Connection class had an option for providing the "address" of the dbus. I gave the address and as expected it worked :) The gst-switch-srv too confirmed the connection. However, the main problem arose when I tried calling a method. The dbus modules have been implemented such that they seem to be looking for the path at "org.freedesktop.dbus". However, in reality such a path does not exist in the custom dbus defined by the gst-switch-srv. So, it simply gives an exception stating that it didn't find anything at "org.freedesktop.dbus". So I was left again with GDbus :) I read the C implementations and tried to make sense with the corrosponding Python classes. Finally, after a day I came across a tool "d-feet". This is a graphical reader of the dbus. It was probably the first thing that I had tried. It has an option for custom bus addresses. However, providing the address simply didn't work. But the source code of the module was indeed of lots of use. D-feet internally uses the GDbus modules for connections. The implementation of the introspect method here gave a clear idea of what I had to really do!

Today

Using the d-feet code I tried out a test script. Its over here. Using this kind of a script, I can control the PIP mode of the gst-switch-srv. And, it doesn't crash the gst-swicth-srv :D The methods where I get information work perfect as they used to.

Todo

• I need to define a class structure for these dbus interactions (the Controller class I talked about in a previous blog).
• Although the above testing script is working, there are some cases where does cause some undesired results. These have to be dealt with too.