<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">These are all good and valid points. For #1 through #4, I intend to address these by implementing my own CELT encoder and decoder. Maybe that will enable me to solve these issues, maybe it won't. I don't know because I don't truly understand the nature of the problems (yet). The most likely outcome is that solving these issues would require such overhead in the extension packets that it won't even be worth it. But I won't know until I try.</span><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">But solving the first four issues is completely irrelevant if players can't handle these packets.</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px">In the HA thread, you expressed concern that I would be creating a rogue extension. This is the last thing I want to do. To me, it would be neat if extension packets as a concept on their own were standardized. My current idea is like this:</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Have a Type-III packet that signals zero frames followed by the padding length descriptor. Then within that padding, start with some sort of unique identifier that runs until the next null byte, then have the arbitrary payload.</div>
<div style="font-family:arial,sans-serif;font-size:13px"><br></div><div style="font-family:arial,sans-serif;font-size:13px">Current decoders should see a frameless Type-III packet and simply discard it. Later decoders would simply know to check for those packets, and then check to see if the unique identifier is anything they're interested in.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 9:53 PM, Jean-Marc Valin <span dir="ltr"><<a href="mailto:jmvalin@jmvalin.ca" target="_blank">jmvalin@jmvalin.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
We have already pointed out multiple times in the HydrogenAudio thread (<br>
<a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=99653" target="_blank">http://www.hydrogenaudio.org/forums/index.php?showtopic=99653</a> ) why we<br>
think this is a bad idea. These include (off the top of my head):<br>
<br>
1) The Opus decoder does not have a bit-exact definition<br>
2) It would require a bit-exact resampler too (the one from opus-tools<br>
isn't bit-exact even in fixed-point)<br>
3) Opus has features that improve the quality by making the residual<br>
larger, so you can't have both efficient lossless and efficient<br>
non-lossless.<br>
4) It would result in something very complex for little gain over (e.g.)<br>
simply packing an alternate FLAC stream next to the Opus stream in the<br>
Ogg file.<br>
5) Even if it was a good idea, such kind of extension would need to go<br>
through the IETF.<br>
<br>
Jean-Marc<br>
<div><div class="h5"><br>
On 12/13/2013 12:34 AM, William Swartzendruber wrote:<br>
> I have a project I'm investigating. The goal is to basically add<br>
> lossless extensions to Opus. You have an Opus stream with standard<br>
> packets, but interwoven in there are extension packets that contain the<br>
> residuals. Ideally, compliant decoders play the stream back and ignore<br>
> the extension packets. This (hopefully) makes the "lossless" stream<br>
> compatible with existing players. Specialized decoders decode the<br>
> standard Opus (CELT) packets, the residual extension packets, and then<br>
> combines them to reproduce a bit-exact stream to the original PCM.<br>
><br>
> Now those of you familiar with how Opus works will readily identify some<br>
> issues with why this might be completely impossible. Those problems are<br>
> to be explored later. First, I need to know that current players can<br>
> even handle streams with extension packets. The problem is that,<br>
> currently, these packets are completely undefined.<br>
><br>
> My current idea is to have a packet with zero frames (illegal) and then<br>
> put the extension data in that (illegal) packet's padding area. As I<br>
> remember it, this is against the Opus RFC for at least two reasons:<br>
><br>
> 1. An Opus packet must have at least one frame.<br>
> 2. A packet's padding may not contain anything but null bytes.<br>
><br>
> However, the spec also says packets that violate this should simply be<br>
> ignored, which is what I'm hoping players do. Another question is how<br>
> streams with extension packets get muxed into containers like Matroska.<br>
> Will mkvtools drop the extension packets?<br>
><br>
> So how should I go about structuring these things? I assume somewhere<br>
> in the padding I need to place an identifier in there so that later<br>
> decoders don't confuse my extension packets with other types.<br>
><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> opus mailing list<br>
> <a href="mailto:opus@xiph.org">opus@xiph.org</a><br>
> <a href="http://lists.xiph.org/mailman/listinfo/opus" target="_blank">http://lists.xiph.org/mailman/listinfo/opus</a><br>
><br>
<br>
</blockquote></div><br></div></div>