Encoder Consensus in Gstreamer 0.11

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Encoder Consensus in Gstreamer 0.11

Benjamin Schwartz
On behalf of PiTiVi and Transmageddon, I present a first proposal to unify
encoder properties in Gstreamer 0.11.

Right now, every encoder is a unique special snowflake, so we have the
same core encoder functionality exposed through countless different
incompatible element interfaces.  This is a significant hardship for
gstreamer developers, especially when writing GUI tools.  Currently,
exposing basic, fundamental encoding parameters, like bitrate or quality,
requires special-casing every implementation of every codec.

This wiki page presents a set of encoder properties that cover a range of
basic audio and video encoder features in a neutral, direct way:

http://gstreamer.freedesktop.org/wiki/ZeroPointEleven/EncoderConsensus#ConsensusProperties

I propose that this set of properties become mandatory* for all encoders
in Gstreamer 0.11, to end the present absurdity.

--Ben

*: To quote the page, "It is not expected that every encoder provide all
of these properties, or that encoders provide only these properties.
Rather, if an encoder provides the functionality described by one of these
consensus properties, it should conform to the consensus property and not
invent its own incompatible property. For functionality not covered here,
encoder developers are free to invent any kind of new property."
"Mandatory" means that nonconforming encoders won't be accepted into -good
(or maybe even -bad).



_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Encoder Consensus in Gstreamer 0.11

Stefan Sauer
On 08/19/11 21:09, Benjamin M. Schwartz wrote:
On behalf of PiTiVi and Transmageddon, I present a first proposal to unify
encoder properties in Gstreamer 0.11.
Right now, every encoder is a unique special snowflake, so we have the
same core encoder functionality exposed through countless different
incompatible element interfaces.  This is a significant hardship for
gstreamer developers, especially when writing GUI tools.  Currently,
exposing basic, fundamental encoding parameters, like bitrate or quality,
requires special-casing every implementation of every codec.

This wiki page presents a set of encoder properties that cover a range of
basic audio and video encoder features in a neutral, direct way:

http://gstreamer.freedesktop.org/wiki/ZeroPointEleven/EncoderConsensus#ConsensusProperties
Added the link to
https://bugzilla.gnome.org/show_bug.cgi?id=118142
I propose that this set of properties become mandatory* for all encoders
in Gstreamer 0.11, to end the present absurdity.

--Ben

*: To quote the page, "It is not expected that every encoder provide all
of these properties, or that encoders provide only these properties.
Rather, if an encoder provides the functionality described by one of these
consensus properties, it should conform to the consensus property and not
invent its own incompatible property. For functionality not covered here,
encoder developers are free to invent any kind of new property."
"Mandatory" means that nonconforming encoders won't be accepted into -good
(or maybe even -bad).

would it make sense to use "-1" for 'ignore-bitrate', 'ignore-buffer-limit' and 'ignore-quality'.

complexity vs. quality is not clear to me. speex has it, but I wonder if speex could derive quality and complexity from one unifies quality setting.

All this could be implemented as an interface to also document the expected behavior there. In an interface we would need to contrain the range though and thus need to use GstPropertyProbe on the implementations to get the real supported ranges.

Stefan

_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Encoder Consensus in Gstreamer 0.11

Olivier Crête-3
In reply to this post by Benjamin Schwartz
On Fri, 2011-08-19 at 15:09 -0400, Benjamin M. Schwartz wrote:
> http://gstreamer.freedesktop.org/wiki/ZeroPointEleven/EncoderConsensus#ConsensusProperties
>
> I propose that this set of properties become mandatory* for all encoders
> in Gstreamer 0.11, to end the present absurdity.

You may also want to look at the H.264 interface that Miguel Verdu
proposed:
http://meego.gitorious.org/maemo-multimedia/meego-gst-interfaces/blobs/master/gst-libs/gst/interfaces/meegoh264encoder.h

--
Olivier Crête
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Encoder Consensus in Gstreamer 0.11

Benjamin Schwartz
In reply to this post by Stefan Sauer
On 08/20/2011 03:45 AM, Stefan Kost wrote:
> Added the link to
> https://bugzilla.gnome.org/show_bug.cgi?id=118142

Thanks, I didn't know about that bug.

> would it make sense to use "-1" for 'ignore-bitrate',
> 'ignore-buffer-limit' and 'ignore-quality'.

I don't think we can use -1 for ignore-quality because some encoders (e.g.
vorbisenc) support negative quality.

For ignore-bitrate, I thought that it would be better not to do this
because it would prevent elements from setting the bitrate limits
correctly.  Some encoders limit the range of bitrates that the user may
specify, because the encoder cannot produce bitrates all the way to zero.
 This seems like useful information to convey to the user, and limiting
the range of the property seems like a good way to convey it.

We could use -1 for ignore-buffer-limit, but it would break the proposed
system in which the minimum buffer limit is only 0 when the encoder
supports hard CBR.

> complexity vs. quality is not clear to me. speex has it, but I wonder if
> speex could derive quality and complexity from one unifies quality setting.

Nope, complexity and quality are unrelated.  complexity is meant to replace

theoraenc: speed-level
vp8enc: speed
pngenc: compression-level
x264enc: speed-preset
celtenc: complexity
speexenc: complexity


> All this could be implemented as an interface to also document the
> expected behavior there. In an interface we would need to contrain the
> range though and thus need to use GstPropertyProbe on the implementations
> to get the real supported ranges.

I think real ranges and types are valuable.  For example, theoraenc's
quality is an integer [0...63], vorbisenc's is a float [-0.1 ... 1.0], and
x264enc's is an integer [1...50].  We could remap all of these to a fixed
float range (e.g. [0...1.0]), but we would lose the discreteness and
consistency with other tools+docs.

I don't know anything about GstPropertyProbe and interfaces, but I imagine
that most encoders will _not_ implement all of these properties, because
they are not all relevant to every encoder.  We could require encoders to
implement them, even if they are read-only, but I would prefer not to.

If interfaces can express this kind of flexibility (properties that may be
absent, may have different types, and may have different ranges), then I
am all for it.  Maybe interfaces should be upgraded for flexibility in 0.11?

--Ben


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Encoder Consensus in Gstreamer 0.11

Stefan Sauer
On 08/20/11 17:05, Benjamin M. Schwartz wrote:
I think real ranges and types are valuable.  For example, theoraenc's
quality is an integer [0...63], vorbisenc's is a float [-0.1 ... 1.0], and
x264enc's is an integer [1...50].  We could remap all of these to a fixed
float range (e.g. [0...1.0]), but we would lose the discreteness and
consistency with other tools+docs.

I don't know anything about GstPropertyProbe and interfaces, but I imagine
that most encoders will _not_ implement all of these properties, because
they are not all relevant to every encoder.  We could require encoders to
implement them, even if they are read-only, but I would prefer not to.
GInterface is something from the GObject world (aka glib). The advantage of using a GInterface is, that apps can simply check if the element implements the interface and if use it appropriately. We would get the same effect by putting the properties to a GstBaseEncoder.

The problem with properties on the interface or baseclass level is that we have to use a unconstrained value range. Subclasses unfortunately cannot refine that easily (no idea if one could actually do that using g_param_spec_override). The GstPropertyProbe iface allows to e.g. check at runtime if a specific property is available and what the value range is. This could be used to get rid of the -ignore properties as well.

If interfaces can express this kind of flexibility (properties that may be
absent, may have different types, and may have different ranges), then I
am all for it.  Maybe interfaces should be upgraded for flexibility in 0.11?
GInterface is not GStreamer specific and is not under our control. Btw. it might also be worth to consider to have a different set of properties for audio and video encoders. We have separate baseclasses anyway.

Stefan
--Ben

_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel