[gst-devel] MediaServices GSoC project discussion

[Stefan Kost]

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