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.
Subscribe to:
Post Comments (Atom)
2 comments:
http://www.w3.org/TR/xslt#section-Conditional-Processing
http://www.w3.org/TR/xslt#section-Extension-Functions
http://www.xmlsoft.org/XSLT/extensions.html
Just some things for possible inspiration :)
I think trying to put the elements and the pipeline directly in the xml is a mistake.
I've been writing a transcoding app for 3 years with gstreamer. And we started on a similar path to discover that the gstreamer pipeline needed a lot of tweaks in some situations and that it could easily tied to applicative operations.
So I would suggest that you write in a profile what you want in terms of file type and codec etc.. rather then directly use the gstreamer elements.
And have the application interpret this profile and decide which elements it wants to build and how. This way you will stay in control of your pipeline.
And it will be easier for a a user to read/write a profile.
You could always have options to the builder of this pipeline if you want to add plugin preferences etc.
Also maybe as a general advice.. try not to think in terms of a gst-launch pipeline, using different objects for each conceptual part of this pipeline instead.. build them individually and then link them together.. trying to make a complete gst-launch and execute it will limit your app a lot!
Nice things to seperate for example are each : FileDescriptor related concept (file/http/socket ) Demuxing objects, objects decoding compressed data, objects making modifications to uncompressed data , objects encoding data, objects muxing data... objects that are can do other gstreamer transformation like a tee etc.. should also be individualy buildable...
After that , there not much you can't do .. :)
Just my humble opinion :)
hexa
Post a Comment