Encoder Consensus in Gstreamer 0.11

Stefan Kost ensonic at hora-obscura.de
Sat Aug 20 00:45:44 PDT 2011


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
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110820/79a1bcb1/attachment.html>


More information about the gstreamer-devel mailing list