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 |
Added the link toOn 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 https://bugzilla.gnome.org/show_bug.cgi?id=118142 would it make sense to use "-1" for 'ignore-bitrate', 'ignore-buffer-limit' and 'ignore-quality'.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). 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 |
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 |
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 |
On 08/20/11 17:05, Benjamin M. Schwartz wrote:
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.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. 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. 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.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? 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 |
Free forum by Nabble | Edit this page |