[Bug 757049] tsdemux: Add support for Opus

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Sat Oct 24 15:15:08 PDT 2015


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

--- Comment #10 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
> 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?

> The idea here is that each frame tells you how much of it has to be skipped
> at the beginning or end. So that if you would have to skip 1.5 frames, and
> you would start reading at the second frame, you would still know to skip
> 0.5 frames.
> 
> Skipping is however only allowed at the beginning or end, not in the middle
> of the stream.

Of course.

> So this is the same as what it does for the beginning in the Ogg header,
> just per packet.

I'm not sure where we're disagreeing/misunderstanding each other now tbh.

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).

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


More information about the gstreamer-bugs mailing list