Re: [0.11] gst-plugins-base: audio: rework audio caps.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [0.11] gst-plugins-base: audio: rework audio caps.

Sebastian Dröge-7
On Thu, 2011-08-18 at 10:23 -0700, Wim Taymans wrote:

> +struct _GstAudioFormatInfo {
> + GstAudioFormat format;
> + const gchar *name;
> + GstAudioFormatFlags flags;
> + gint endianness;
> + gint width;
> + gint depth;
> + guint8 silence[8];
> + guint unpack_size;
> + GstAudioFormatUnpack unpack_func;
> + GstAudioFormatPack pack_func;
> +};
Isn't there some redundancy here now? endianness/width/depth are
expressed by the format already.

If only the GstAudioFormat stays it will be impossible to have, e.g. 16
bit samples in 4 bytes, which is something that some codecs would
require and we would need to do conversions inside the element then.

Also, can we get support for non-interleaved channels now that
everything is changed anyway? Just add it as an additional flag to
GstAudioFlags :)

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [0.11] gst-plugins-base: audio: rework audio caps.

Wim Taymans
On 08/19/2011 08:52 AM, Sebastian Dröge wrote:

> On Thu, 2011-08-18 at 10:23 -0700, Wim Taymans wrote:
>
>> +struct _GstAudioFormatInfo {
>> + GstAudioFormat format;
>> + const gchar *name;
>> + GstAudioFormatFlags flags;
>> + gint endianness;
>> + gint width;
>> + gint depth;
>> + guint8 silence[8];
>> + guint unpack_size;
>> + GstAudioFormatUnpack unpack_func;
>> + GstAudioFormatPack pack_func;
>> +};
>
> Isn't there some redundancy here now? endianness/width/depth are
> expressed by the format already.

The FormatInfo gives info about the GstAudioFormat (and is also const).

>
> If only the GstAudioFormat stays it will be impossible to have, e.g. 16
> bit samples in 4 bytes, which is something that some codecs would
> require and we would need to do conversions inside the element then.

That is correct. Instead of doing all possible formats under the sun, we
limit ourselves to some of the more common ones. I would expect elements
that have a format not in the list to do an internal conversion (using
some helper function in the audio library). If there is a common format
we miss, we can also add it to the list.

>
> Also, can we get support for non-interleaved channels now that
> everything is changed anyway? Just add it as an additional flag to
> GstAudioFlags :)

Still pondering on that.

Wim

>
>
>
> _______________________________________________
> 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