Encoder Consensus in Gstreamer 0.11

[Benjamin M. Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110820/ebf66199/attachment.pgp>