Demuxed opus packet is corrupt

[ebekebe]

I generated an opus stream in gstreamer and muxed it into ts: gst-launch-1.0 audiotestsrc ! opusenc ! mpegtsmux ! filesink location=out.ts.

The opus stream in this file has 160 byte packets, but when I decode it with ts-demuxer, it returns 163 byte packets, where the first 3 bytes are always the same: [127, 224, 160]. If I remove the first 3 bytes manually, the decoder can decode the stream again.

I don't have a good understanding of the ts format, so I don't why this happens. For now, I can work around this by slicing off the first three bytes, but it would be nice to have this fixed here.

[gliese1337]

Odd. If it were two bytes, I would suspect self-delimited Opus packet headers, but I don't know why there would be three.
Do you see similar issues with any other encodings?

[ebekebe]

I use h264 with opus in one ts stream. Only the opus data is weird. H264 has no issues.

[ak-s]

the first 3 bytes are always the same: [127, 224, 160]

It is opus_control_header, see https://opus-codec.org/docs/ETSI_TS_opus-v0.1.3-draft.pdf chapter 6
control_header_prefix is 11-bit 0x3FF
In general, the header has a variable length, but for this case:

• [127, 224] is 16-bit 0x7FE0, right shift by 5: 0x7FE0 >> 5 == 0x3FF
• [160] is payload_size

BLTN...

[gliese1337]

It is opus_control_header, see https://opus-codec.org/docs/ETSI_TS_opus-v0.1.3-draft.pdf chapter 6 control_header_prefix is 11-bit 0x3FF In general, the header has a variable length, but for this case:

Is it safe to say, then, that this is not an issue with the demuxer?