[Bug 757049] tsdemux: Add support for Opus

[GStreamer (GNOME Bugzilla)]

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

--- Comment #11 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Tim-Philipp Müller from comment #10)
> > That's not what it does btw. Also we don't have the trim_start in the
> > streamheader in mpegts (the descriptor only has the channel layout).
> 
> I think that's exactly what it does, it's just that you generate the header
> from a given fake opus header and just add the details like channel layout
> in addition, if needed. So we know the trim_start value is 0 at first (which
> I missed), unless trim_start is used multiple times, which it shouldn't be,
> no?

In the streamheader it's for the complete stream, in the MPEGTS frame it's for
this specific frame. That is, per frame the trim_start value can't be bigger
than the duration of that frame, but you can have it on the following frame too
if the complete first frame is to be skipped.

That's the difference I wanted to point at :)

> I don't mind the updating of stream header per se, just that it was
> retrieved and mapped for every single packet.
> 
> The fact that there might be multiple packets at the beginning that all have
> the trim_start set (legitimately) because more than one packet should be
> skipped indicates to me that this really should go into a meta and that we
> should not update the streamheader with this. Otherwise the decoder would
> have to differentiate between real format changes and
> just-updating-the-pre-skip-value, that sounds messy and not in line with how
> we do things usually (we don't keep state across renegotiation usually, do
> we).

I agree, this should be a generic skipping thing as a GstMeta and then
GstAudioDecoder can just handle that. Or we could indeed do it with some
segment tricks instead, but I would like to keep those out of the demuxers.

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