[Bug 746617] opusenc: headers are never sent

[GStreamer (GNOME Bugzilla)]

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

--- Comment #40 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Olivier Crête from comment #38)
> If I understand correctly the "header" produced by opusenc is actually Ogg
> specific, so it should probably go into oggmux?

Yes, having it in opusdec and opusenc is hurting my eyes :) But I think this
header is also used by matroskamux/demux, needs to be checked. Which seems
weird... but oh well.

> Also, I don't think we have a way in Gst 1.x to express channel ordering in
> caps anymore? Should we just always encode  in GStreame order and put the
> mask on the audio/x-opus caps ?

I think for the audio/x-opus caps we will need to express everything that goes
into the Ogg header somehow. Meaning that we also need to express arbitrary
channel orders. We can just use a GST_TYPE_ARRAY of integers for that, just
like it is stored in the Ogg header and also expected by the Opus API.
It's not nice but I think the best we can do.

opusdec of course has to reorder channels into the GStreamer channel order
then, and also opusenc should potentially reorder channels if downstream
requests a different "Opus channel map".

(In reply to Ilya Konstantinov from comment #39)
> (In reply to Olivier Crête from comment #38)
> > Also, I don't think we have a way in Gst 1.x to express channel ordering in
> > caps anymore? Should we just always encode  in GStreamer order and put the
> > mask on the audio/x-opus caps ?
> 
> opusenc cannot receive channels in any order but the GStreamer order, so why
> would it do anything else?
> 
> If to judge by other audio sources, opusdec should reorder if needed, to
> output GStreamer order.

All true, but see above. We need to be able to express other orders in the
audio/x-opus caps, e.g. to handle multichannel streams coming from containers
that define a different order (MPEGTS). opusenc/dec need to reorder then to
make sure only the GStreamer order ever appears in audio/x-raw streams.

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