[gst-devel] MediaServices GSoC project discussion

[Stefan Kost]

hi,
Roberto Fagá schrieb:
> Hi all!
>
> Just to figure out how is going the work now, I'm trying to figure out
> how to represent a XML Encoding Profile. I posted in my dev blog [1] a
> way like banshee's profiles, representing the possible conversions as
> Gstreamer pipelines. But Antoine (hexa) suggested a way to represent
> them by capabilities, not by pipelines with gstreamer elements, and
> the application connect the possible elements to construct a pipeline,
> so a conversion can run with different elements - which are possible
> to use in each different device. This looks the best way to do
> profiles, but also recover the problem of properties - how can
> MediaServices offer useful properties to change? Like in an audio
> conversion, how can I presume that all mp3 encoders have bitrate and
> quality properties, with these exactly names?
One idea would be that we make encoders support the preset iface and 
then we can offer the presets to the user. Not perfect, but it would 
allow to cover certain use-cases: archival, mobile-device-playback, 
web-playback, streaming. I am totally aware that it can not be precisely 
defines what "mobile-device-playback" means :/
>  Also, how can I
> represent the connection between pseudo-elements without using
> pipeline in itself? -- this second question I probably can only says
> what are the src and sink formats, but we have some formats that the
> input is the same of output (like id3v2mux), so how can I exactly do
> this?
>   
As far as I know all the elements involved have different input and 
output caps. Unfortunately we still have several elements with ANY-caps 
and this could be problemeatic (e.g. id3v2mux). Elements should imho 
really list what the support.

Stefan
> I'm not sure if I'm being clear on my doubts, if don't please just ask
> what in this same email.
>
>
> Thanks everyone!
>
> Roberto
>
>
> [1] - http://gstmediaservices.blogspot.com/2008/07/two-weeks-without-reporting-but-here-i.html
>
> On Sun, Jul 13, 2008 at 10:13 AM, Stefan Kost <ensonic at hora-obscura.de> wrote:
>   
>> hi,
>>
>> my student would need some feedback and discussion regarding his project. He
>> is not implementing a spec, so his work is not that straight forward. Please
>> take some time, read through the mail and let us know what you think. Thanks
>> a lot!
>>
>> = MediaServices =
>>
>> In [2] we have started some discussion to offer some gstreamer related ui
>> support as a extra library. In the MediaServices GSoc project [1] we're
>> studying
>> the possibillity to have basic building blocks of encoding dialogs together
>> with
>> a bunch of convinience methods. For the UI side the aim is to come up with
>> something usable for normal users - not a power users dialog that allows to
>> tweak every deatail of an encoder.
>>
>> I see two basic use-cases:
>>
>> a) an application like buzztard, pitivi, thoggen, jokosher wants to encode a
>>   project into a file.
>> b) an application wants to transcode existing file into one format (e.g. a
>>   conduit plugin for a nokia tablett or an ipod).
>>
>> Whats the differences:
>> - format:
>>  a) needs to provide some info of the data it wants to encode (hierarchical
>>     GstStructure?)
>>  b) data format can be read from decodebin(2).
>> - runs
>>  a) is about one run (one output file)
>>  b) is about transcoding a list of files
>>
>> Based on that, one possible design could be that the library offers to
>> create a
>> (vbox) widget containing the following
>>
>> |                +--------------+ +-------------+ |
>> | Container      |<container> |v| | Preferences | |
>> |                +--------------+ +-------------+ |
>>
>> and this for each stream:
>>
>> |                +--------------+ +-------------+ |
>> | <stream name>  |<encoder>   |v| | Preferences | |
>> |                +--------------+ +-------------+ |
>>
>> Containers are avi,mp4,..., stream types are audio/video/subtitles.
>> The application would pack this in its own dialog. For a transcoder this
>> could
>> be whats proposed at [3]. For a encoder it would probably have a filechooser
>> button below. For thoggen [4] it could possible be under "video stream".
>>
>> The library would quiery the registry for available muxers and parse their
>> template caps to build lists of possible encoders, Atleast that would be
>> redundant code in apps.
>>
>> Questions:
>> 1) would encoding applications like to restrict possible formats somehow?
>> 2) it still quite open how we approach generic settings for encoders/muxers.
>> Any
>> ideas here. Having something like the s-expressions in banshee profiles [5]?
>> We
>> have some open discussion about the topic in bugzilla too [6],[7].
>> 3) suppose the source is 1 audio stream
>>   - it might be desirable to filter the muxer list to offer only usefull
>> entried
>>    (one would put a pcm normally into wav and not into an avi)
>>   - it also needs to offer formatters then
>>
>> Please comment,
>>
>> Stefan
>>
>>
>> [1] http://gstreamer.freedesktop.org/wiki/MediaServices
>> [2] http://gstreamer.freedesktop.org/wiki/DesignDiscussions
>> [3]
>> http://gstreamer.freedesktop.org/wiki/MediaServices#head-085a598d7c7e1fac6d3ab9e40681a05b25456c71
>> [4] http://thoggen.net/images/0.7/config-dialog-2.png
>> [5] http://svn.gnome.org/viewvc/banshee/trunk/banshee/data/audio-profiles/
>> [6] http://bugzilla.gnome.org/show_bug.cgi?id=118142
>> [7] http://bugzilla.gnome.org/show_bug.cgi?id=522205
>>
>>