[opus] Extension Packets?

[Jean-Marc Valin]

Hi,

We have already pointed out multiple times in the HydrogenAudio thread (
http://www.hydrogenaudio.org/forums/index.php?showtopic=99653 ) why we
think this is a bad idea. These include (off the top of my head):

1) The Opus decoder does not have a bit-exact definition
2) It would require a bit-exact resampler too (the one from opus-tools
isn't bit-exact even in fixed-point)
3) Opus has features that improve the quality by making the residual
larger, so you can't have both efficient lossless and efficient
non-lossless.
4) It would result in something very complex for little gain over (e.g.)
simply packing an alternate FLAC stream next to the Opus stream in the
Ogg file.
5) Even if it was a good idea, such kind of extension would need to go
through the IETF.

	Jean-Marc

On 12/13/2013 12:34 AM, William Swartzendruber wrote:
> I have a project I'm investigating.  The goal is to basically add
> lossless extensions to Opus.  You have an Opus stream with standard
> packets, but interwoven in there are extension packets that contain the
> residuals.  Ideally, compliant decoders play the stream back and ignore
> the extension packets.  This (hopefully) makes the "lossless" stream
> compatible with existing players.  Specialized decoders decode the
> standard Opus (CELT) packets, the residual extension packets, and then
> combines them to reproduce a bit-exact stream to the original PCM.
> 
> Now those of you familiar with how Opus works will readily identify some
> issues with why this might be completely impossible.  Those problems are
> to be explored later.  First, I need to know that current players can
> even handle streams with extension packets.  The problem is that,
> currently, these packets are completely undefined.
> 
> My current idea is to have a packet with zero frames (illegal) and then
> put the extension data in that (illegal) packet's padding area.  As I
> remember it, this is against the Opus RFC for at least two reasons:
> 
> 1. An Opus packet must have at least one frame.
> 2. A packet's padding may not contain anything but null bytes.
> 
> However, the spec also says packets that violate this should simply be
> ignored, which is what I'm hoping players do.  Another question is how
> streams with extension packets get muxed into containers like Matroska.
>  Will mkvtools drop the extension packets?
> 
> So how should I go about structuring these things?  I assume somewhere
> in the padding I need to place an identifier in there so that later
> decoders don't confuse my extension packets with other types.
> 
> 
> 
> 
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus
>