GStreamer-devel

MediaServices GSoC project discussion

Classic

List

Threaded

5 messages Options

Stefan Sauer

MediaServices GSoC project discussion

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

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Roberto Fagá

Re: MediaServices GSoC project discussion

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 <[hidden email]> 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
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Tim-Philipp Müller-2

Re: MediaServices GSoC project discussion

On Thu, 2008-07-24 at 23:09 -0300, Roberto Fagá wrote:

Hi,

> [H]ow can I presume that all mp3 encoders have bitrate and
> quality properties, with these exactly names?

You can't really, I think. We don't have interfaces for this yet or even
de-facto standards. It's different for each element. Not sure what you
can do about that in the short term (other than maybe make sure they all
support a number of certain profiles which you could then select by
name).

> ..., but we have some formats that the input is the same of output
> (like id3v2mux), so how can I exactly do this?

id3v2mux's output will (should) always be application/x-id3 whatever the
input format.

Cheers
-Tim

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Stefan Sauer

Re: MediaServices GSoC project discussion

In reply to this post by Roberto Fagá

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 <[hidden email]> 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
>>
>>

Roberto Fagá

Re: MediaServices GSoC project discussion

Hallo everyone,

I'm trying like Antoine's suggestion to do EncodingProfiles generic,
to use any possible element available. First, thanks Tim and Stefan,
I'll probably need to use some preset form, as I'm having some
problems with my actual way of implementing it. I'm writing above my
current problems of using generic elements, like in [1], so everyone
plz answer:

How can I be sure that a found element is right? For an example we
have audioconvert element and can have some other filter that converts
some audio format to another. So, should I check in for
Filter/Converter/Audio klass? If so, how can I presume that the only
case (at least is what I found for now) is the id3v2mux and id3mux
which do the same thing and have different klasses and different Sinks
(id3v2mux has ANY x id3mux has audio/mpeg layer=3)?

Also, how can I search for an alternative element for xingmux, as an
example, if it has the same input and output and nothing more?

Connections - if I code the connections in XML, how can I be sure that
alternative elements will act exactly as what I tested?

I'm not sure if I can let the application so open to find new
elements, I'm afraid to have some situation where I find an element,
for an example, and it doesn't do what I expect and the conversion
never happen. I'm thinking in try different pipelines with the
different elements found, but even in this case and even wasting so
much cpu, I can't be sure if the output format will be exactly as user
expects - in the constructed pipeline I can trow a effect element for
an example which changes the audio/video.

Thx
Roberto

[1] - http://code.google.com/p/gst-media-services/source/browse/trunk/profiles/testing_profiles.xml?r=15

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel