[gst-devel] MediaServices GSoC project discussion

[Roberto Fagá]

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? 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?

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
>