<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> On 08/19/11 21:09, Benjamin M. Schwartz wrote: <blockquote cite="mid:4E4EB4F1.6080500@fas.harvard.edu" type="cite"> <pre wrap="">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: <a class="moz-txt-link-freetext" href="http://gstreamer.freedesktop.org/wiki/ZeroPointEleven/EncoderConsensus#ConsensusProperties">http://gstreamer.freedesktop.org/wiki/ZeroPointEleven/EncoderConsensus#ConsensusProperties</a> </pre> </blockquote> Added the link to <a href="https://bugzilla.gnome.org/show_bug.cgi?id=118142">https://bugzilla.gnome.org/show_bug.cgi?id=118142</a> <blockquote cite="mid:4E4EB4F1.6080500@fas.harvard.edu" type="cite"> <pre wrap=""> 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). </pre> </blockquote> 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 <blockquote cite="mid:4E4EB4F1.6080500@fas.harvard.edu" type="cite"> <pre wrap=""> <fieldset class="mimeAttachmentHeader"></fieldset> _______________________________________________ gstreamer-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </pre> </blockquote> </body> </html>