[Bug 757049] tsdemux: Add support for Opus

[GStreamer (GNOME Bugzilla)]

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

Tim-Philipp Müller <t.i.m at zen.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t.i.m at zen.co.uk

--- Comment #5 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
 > Sure, but the effect would be the same :) 

That's why I said "it would be nicer".

I've had a quick look at the spec now, and think I understand what you're
trying to do there with the streamheader stuff. Basically, streamheaders
contain a value for trim_start as well, and if it's not consistent with the one
in the packet header, then we fix up the streamheaders, ok.

- the code retrieves caps + streamheader buffer + maps streamheader buffer for
every single packet. That's not needed as far as I can tell, we should do that
only in case trim_start is set and >0. Maybe move the fixing up into a separate
function.

- currently opusdec doesn't seem to handle the streamheader=(buffer)... case,
only the array of buffers case


> Yes, if every single packet has a different trim_start value. But actually
> it's not 100% correct, the spec says that it can only be at the beginning of
> a stream and applies to the current packet. Once a packet was there without
> the field, the field can't be used again.

Unless there was an end_trim I guess, for seamless concatenation? Not sure if
we really need to do all this sanity/consistency checking at all.


> Also we need to handle trim_stop somehow. I think the best would be to
> introduce a GstMeta for this, however it would have to be used by tsdemux
> (and matroskademux and qtdemux) and opusdec/opusenc. So should probably go
> in libpbutils or libgstaudio?

Were you thinking of an opus-specific meta? I was actually thinking of a more
general coded-audio meta for this, which could be used for mp3/aac etc. as well
then.

I think we should just completely ignore the trim_start and trim_end stuff for
now and add a FIXME, and sort it out in a more general way for all codecs, also
see bug #746109 and especially bug #740196.

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