[Bug 751605] audio: Add proper support for non-interleaved / planar audio

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=751605

--- Comment #21 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to George Kiagiadakis from comment #20)
> (In reply to Sebastian Dröge (slomo) from comment #19)
> > ::: gst-libs/gst/audio/audio-buffer.h
> > @@ +52,3 @@
> > +  gpointer    *planes;
> > +
> > +  GstBuffer   *gstbuffer;
> > 
> > Why the gst prefix?
> 
> Well, because the parent structure is also a buffer, so then you write stuff
> like buffer->buffer that is not so readable, but it's not a big deal. I can
> remove it.

Without the gst prefix seems nicer but if someone disagrees, I don't care
enough :)

> > ::: gst-libs/gst/audio/gstaudiometa.h
> > @@ +156,3 @@
> > + * Since: 1.16
> > + */
> > +struct _GstAudioMeta {
> > 
> > Should it maybe be get the word "planar" in here, or do you expect this to
> > be also useful for interleaved audio somehow?
> 
> The intention was to be able to attach it in both interleaved and
> non-interleaved buffers. Although, for interleaved I haven't thought of a
> use case.

Ok, we can think about that when it happens I guess. There's padding so it can
be extended by something if needed.

> > @@ +161,3 @@
> > +  GstAudioInfo   info;
> > +  gsize          samples;
> > +  gsize          *offsets;
> > 
> > Is it allowed to have multiple channels with the same offset, to cheaply
> > duplicate a channel?
> 
> Sure, why not.

Maybe document that then. It might have some implications for code working on
the channels (as the pointers are aliasing then)

> > @@ +180,3 @@
> > +GstAudioMeta * gst_buffer_add_audio_meta (GstBuffer *buffer,
> > +                                          const GstAudioInfo *info,
> > +                                          gsize samples, gsize offsets[]);
> > 
> > This should maybe sanity-check the buffer size against the number of samples?
> 
> There is a check in the map function. But now I am thinking, what if you are
> duplicating channels in the way you just said above? The check will be
> inaccurate.
> 
> Maybe we can check that the highest offset + samples * bps is contained in
> the buffer

Or do that check for each offset, yes

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.