[gst-devel] [RFC] Encoding and Profiles

Stefan Kost ensonic at hora-obscura.de
Thu Oct 29 19:34:38 CET 2009

Edward Hervey schrieb:
> On Tue, 2009-10-20 at 13:12 +0100, Robert Swain wrote:
>> Hello,
>> 2009/10/19 Edward Hervey <edward.hervey at collabora.co.uk>:
>>>  I have been working lately on researching ways to make the whole
>>> encoding experience better and more streamlined for applications using
>>> GStreamer, and have come up with a proposal.
>>>  You will find the proposal below, and attached to the mail the
>>> research and proposed C API.


>> * Restriction-related
>> ** Profile/level restrictions
>> ** Device-specific restrictions
>> My point is that codec elements always have rather specific
>> configuration options and it would be good to maintain some kind of
>> range of quality option presets for each encoder that trade off speed
>> and quality for a given bit rate. If these options are included in
>> each target preset it will greatly increase maintenance and it's a big
>> enough job as it is. The whole set up lends itself well to this as
>> target devices could just override options as necessary.
>   Profile/Level are clear restrictions. If you choose those, you're
> already limiting the rest of the choices (1)
>   Then amongst the remaining choices I can only think three ways of
> going:
>   * Expose all remaining element-specific options... 
>   * Having a Quality/Speed setting ranging from Low-Quality/Fast to
> HighestQuality/Sloww
>   * A mix of the two :(
> (1): that reminds me... if you select a certain profile that limits the
> range of some option... how do we report that ?

This is a general restriction on e.g. GObject properties. E.g. in v4l2src I
somethimes would like to limmit the real value range once the device has been
openend. We can do that for caps, but not for properties. Sure we have
GstPropertyProbe for it.


More information about the gstreamer-devel mailing list