An alpha for python version

Today I'm releasing an alpha version of gstreamer-media-services, which you can test and report possible bugs. Here you can download it, is not so usable, but you can check how is going the project's idea. Just take care with your testing video and audio files, program is not handling overwrite cases!

I've been talking with Stefan and I'll probably change to implement the gstms core (gstms.py) in C language, to integrate better with gstreamer. I'm just thinking how can I do this, and for now I'm seriously thinking in do it as a gst bin, like decodebin and playbin. I made a diagram of how this could be, profile_diagram, but not sure how could be this XML data profile in sink pad. Probably it's better as a property, but I'm not sure if I can use xml data as gobject property.

Starting Encoding Profiles

Two weeks without reporting, but here I am. I spent this time with implementing the proposed interface, which I did all in glade format and I can easily edit it. Also, the project is detecting format - oh, I spent some hours implementing my own pipeline with decodebin to get info from files in the input and just later I found gst.extend.discoverer... ok, now I have more experience with pipelines, and I'm working in the xml format - I really don't know for now how can I represent the pipelines for themselves, as they need some processing power. For an example, to encode to mp3 I can use id3mux or id3v2mux, but to choose one I need to tell to try each. I saw the method of Banshee, using S-expression, is very useful but I would like to use only XML, just not sure exactly how.

A way that I was thinking is like:
<element id="audioconvert" type="required">
<element id="lame" type="required">
<property id="bitrate" type="optional">
<property id="vbr" type="">
<if expression="vbr!=0"> <!-- vbr!=0 need to use html encoded chars -->
<property>
</property>
</if>
<if expression="vbr != 0">
<element id="xingmux" type="optional">
<element id="id3v2mux" type="optional">
<else>
<if expression="exist(id3v2mux)">
<element id="id3v2mux" type="optional">
<elif expression="exist(id3mux)">
<element id="id3mux type=">
</element>
</elif>

Suggestions?

update: I corrected the XML code which was not appearing.

Reading from Gst Registry

This last week I worked to read info from GstRegistry. This info should help the EncodingProfiles list of possible formats to convert, and also, as commented in my previous post from Laszlo, this could help on recognizing mimetypes supported too.

It was not hard to read plugins and their features - as these all are very well documented in Gstreamer docs, I just lost some time searching the "get_possible_dynamic_pad_templates". The possible dynamic pads templates are included in the static templates... So I read their pads templates and caps, then I just need to parse them in somehow to it help in building profiles list. Parsing registry is needed too to check if plugins from each transcode operation are available.

With registry parsed, now comes the question: How it could help to build the list? A way that I'm thinking on is to rank the features by their caps mimetypes which each one can generate, and then somehow put them in XML list to help others to compose each transcode operation. Another way is to just build a table with these info, allowing re-ordering and filtering according to each feature details. Ideas?