<div dir="ltr"><div><div><div>Hello Jean-Marc,<br><br></div>Assuming that a 48KHz, 20ms 8-bit linear PCM data which is 960 bytes is compressed to 64 bytes (for assumption). The with the Oggs header (4 byte) + 1 segment entry (which is the size of the segment itself) + 64 bytes will amount to (4+1)/(4+1+64) = ~7.2%. This when compared with the original Oggs container itself for the same data payload size (26+1)/(26+1+64) = ~29.6%. Even if it takes a larger payload the Oggs container will still have a larger overhead<br><br></div><div>I also know using the segment table efficiently to hold 1 second of data would reduce the overhead to 1-2%, but increases the processing time on embedded systems. <br><br>Also I should have been more clearer on stream.I meant an audio file. I agree that Opus does not limit the user to use Oggs-Opus container, but having a lite version of the same which can be simple for mid-low microcontrollers would allow users to switch between the two formats (Oggs-Opus or Lite) based on the device requirements/limitations while also enabling conversion tools to be made available easily.<br><br></div><div>I am with you on not creating a new container, but this is a suggestion (microcontrollers benefit a lot with simpler file formats, e.g. lwIP, Tiny FatFs)<br></div><div><br></div>Regards<br></div>Amit<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 12, 2016 at 9:58 AM, 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"><span class="">On 05/12/2016 10:35 AM, Amit Ashara wrote:<br>
> For HMI panels, except for the capture pattern and a single page segment<br>
> entry, other fields are not important, and which results in almost 7%<br>
> overhead for a 20ms raw frame encoded with Opus.<br>
<br>
</span>I'm not sure how you get a 7% overhead. In most uses I've seen, the<br>
overhead is more around 1%.<br>
<span class=""><br>
> At the same time the<br>
> file processing complexity is way too less considering that CRC's do not<br>
> not need to be considered (programmer pods ensure that) and neither is<br>
> seek as these are definite streams to be played.<br>
<br>
</span>CRCs should be a lot cheaper than the codec.<br>
<span class=""><br>
> A custom container is<br>
> OK, but my suspicion is it may spawn more containers as embedded uC<br>
> mostly have less than 1MB on chip flash and less than 256KB on chip RAM<br>
> and most of the uC are executing under 100MHz, with processing more<br>
> towards control and communication.<br>
<br>
</span>If the only goal is to stream audio out... have you considered RTP?<br>
<span class=""><br>
> I like Opus codec, but I wanted to make sure that the Opus org does hear<br>
> the argument for a simpler (lite container) which is spec'ed and makes<br>
> tool development standard. This also gives the options to embedded<br>
> developers to use the lite container or full Ogg container based on the<br>
> requirement, rather than forcing users to Ogg for simple devices...<br>
<br>
</span>We do not force users to use any container. There are existing specs for<br>
using Opus inside Ogg, Matroska (WebM), MP4 and RTP. It will also fit in<br>
any other existing container. We just have no intention of creating new<br>
ones, though nothing prevents you from doing that.<br>
<br>
Cheers,<br>
<br>
Jean-Marc<br>
<span class=""><br>
<br>
> Regards<br>
> Amit<br>
><br>
> On Thu, May 12, 2016 at 7:17 AM, Jean-Marc Valin <<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a>>> wrote:<br>
><br>
> The overhead of Ogg (in file size) is pretty small and it's efficient<br>
> enough for most applications (and uses far less CPU than the codec<br>
> anyway). If anything, you might want to look at optimizing the existing<br>
> Ogg implementation (e.g. like Tremor did in the context of Vorbis).<br>
><br>
> Of course, you're always free to design a new container, but I doubt<br>
> it's worth it and it's a lot of work (e.g. you want your files to be<br>
> seekable, right?). The only thing I can assure you of is that we're not<br>
> going to bring a new "low-complexity" container to the IETF for<br>
> standardization.<br>
><br>
> Cheers,<br>
><br>
> Jean-Marc<br>
><br>
> On 05/12/2016 07:37 AM, Amit Ashara wrote:<br>
> > Hello Ulrich,<br>
> ><br>
> > Putting some extra space is the not the reason for this request. It is<br>
> > the overhead of the frame v/s payload size. Basically larger the payload<br>
> > less % the overhead is (and that makes sense). However the complexity of<br>
> > implementing a read file structure where the file pointer has to go<br>
> > back-forth for reading the payload when multiple segments have to be<br>
> > read, CRC32 (something which needs to be done in SW) is going to<br>
> > increase the time the CPU shall spend in the encapsulation process<br>
> > rather than encoding/decoding process.<br>
> ><br>
> > The answer may be NO, but the question may still be asked.<br>
> ><br>
> > Regards<br>
> > Amit<br>
> ><br>
> > On Thu, May 12, 2016 at 1:29 AM, Ulrich Windl<br>
> > <<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a><br>
> <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>><br>
</div></div>> > <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a><br>
<span class="">> <mailto:<a href="mailto:Ulrich.Windl@rz.uni-regensburg.de">Ulrich.Windl@rz.uni-regensburg.de</a>>>> wrote:<br>
> ><br>
> > >>> Amit Ashara <<a href="mailto:ashara.amit@gmail.com">ashara.amit@gmail.com</a> <mailto:<a href="mailto:ashara.amit@gmail.com">ashara.amit@gmail.com</a>><br>
</span>> > <mailto:<a href="mailto:ashara.amit@gmail.com">ashara.amit@gmail.com</a> <mailto:<a href="mailto:ashara.amit@gmail.com">ashara.amit@gmail.com</a>>>><br>
<span class="">> schrieb am 11.05.2016 um 19:32 in<br>
> > Nachricht<br>
> ><br>
> <<a href="mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ@mail.gmail.com">CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ@mail.gmail.com</a><br>
> <mailto:<a href="mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ@mail.gmail.com">CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ@mail.gmail.com</a>><br>
> ><br>
</span>> <mailto:<a href="mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ@mail.gmail.com">CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ@mail.gmail.com</a><br>
<span class="">> <mailto:<a href="mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ@mail.gmail.com">CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ@mail.gmail.com</a>>>>:<br>
> > > Hello Jean-Marc,<br>
> > ><br>
> > > So for the moment we can assume that this method is also OK to use?<br>
> > ><br>
> > > On Embedded Systems, both SRAM and Flash can be a restricting factor<br>
> > > besides the compute time. To optimize the utilization of embedded<br>
> > > resources, may I suggest a simplification of the Ogg-Opus format and can<br>
> > > this be considered by the Opus org and IETF as an addition?<br>
> ><br>
> > Why would you change the format if one encoder puts some extra space<br>
> > there? Does the spec forbid not to have that extra space? I haven't<br>
> > read it, but I'd be surprised it it were a MUST. If you want to add<br>
> > a MAY NOT, most implementers will object, I guess.<br>
> ><br>
> > ><br>
> > > Regards<br>
> > > Amit<br>
> > ><br>
> > > On Wed, May 11, 2016 at 12:09 PM, Jean-Marc Valin<br>
> > <<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a> <mailto:<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a>><br>
</span>> <mailto:<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a> <mailto:<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a>>>><br>
<div><div class="h5">> > > wrote:<br>
> > ><br>
> > >> On 05/11/2016 12:35 PM, Amit Ashara wrote:<br>
> > >> > I ran the opusenc.exe on a wave file and checked the OpusTag<br>
> > section. My<br>
> > >> > concern is on Total Segment Size being >> than the actual<br>
> data<br>
> > being<br>
> > >> > put. Is this just an example of implementation or does a size<br>
> > of 764<br>
> > >> > BYTES kept as a place holder for putting more data?<br>
> > >><br>
> > >> Yes, opusenc does reserve some space in the header so that<br>
> tags can<br>
> > >> later be modified "in place", without having to rewrite the<br>
> > entire file.<br>
> > >><br>
> > >> Jean-Marc<br>
> > >><br>
> > >><br>
> > >> > 4f 67 67 53 = Oggs<br>
> > >> > 00 = Version<br>
> > >> > 00 = Header<br>
> > >> > 00 00 00 00 00 00 00 00 = Granule Position<br>
> > >> > a5 73 00 00 = Bit Stream Serial Number<br>
> > >> > 01 00 00 00 = Page Sequence Numner<br>
> > >> > 90 a9 36 42 = Checksum<br>
> > >> > 03 = Page Segments<br>
> > >> > ff ff fe = Each Segment Size (TOTAL SIZE IS 764 BYTES)<br>
> > >> > 4f 70 75 73 54 61 67 73 = OpusTags<br>
> > >> > 0b 00 00 00 = Vendor String Length of 11<br>
> > >> > 6c 69 62 6f 70 75 73 20 31 2e 31 = "libopus 1.1"<br>
> > >> > 03 00 00 00 = User Comment List Length of 3<br>
> > >> > 25 00 00 00 = User Comment #0 String Length of 37<br>
> > >> > 45 4e 43 4f 44 45 52 3d 6f 70 75 73 65 6e 63 20 66 72 6f<br>
> 6d 20<br>
> > 6f 70 75<br>
> > >> > 73 2d 74 6f 6f 6c 73 20 30 2e 31 2e 39 = "ENCODER=opusenc<br>
> from<br>
> > >> > opus-tools 0.1.9"<br>
> > >> > 0a 00 00 00 = User Comment #1 String Length of 10<br>
> > >> > 74 69 74 6c 65 3d 48 4f 4c 41 = "title=HOLA"<br>
> > >> > 1e 00 00 00 = User Comment #2 String Length of 30<br>
> > >> > 45 4e 43 4f 44 45 52 5f 4f 50 54 49 4f 4e 53 3d 2d 2d 6d<br>
> 61 78<br>
> > 2d 64 65<br>
> > >> > 6c 61 79 20 32 30 = "ENCODER_OPTIONS=--max-delay 20"<br>
> > >> > 00 00 00... ALL THE WAY TO THE NEXT Oggs Container<br>
> > >> ><br>
> > >> > Regards<br>
> > >> > Amit<br>
> > >> ><br>
> > >> > On Tue, May 10, 2016 at 10:47 PM, Ralph Giles<br>
> > <<a href="mailto:giles@thaumas.net">giles@thaumas.net</a> <mailto:<a href="mailto:giles@thaumas.net">giles@thaumas.net</a>><br>
> <mailto:<a href="mailto:giles@thaumas.net">giles@thaumas.net</a> <mailto:<a href="mailto:giles@thaumas.net">giles@thaumas.net</a>>><br>
> > >> > <mailto:<a href="mailto:giles@thaumas.net">giles@thaumas.net</a> <mailto:<a href="mailto:giles@thaumas.net">giles@thaumas.net</a>><br>
> <mailto:<a href="mailto:giles@thaumas.net">giles@thaumas.net</a> <mailto:<a href="mailto:giles@thaumas.net">giles@thaumas.net</a>>>>> wrote:<br>
> > >> ><br>
> > >> > On 10/05/16 02:37 PM, Amit Ashara wrote:<br>
> > >> ><br>
> > >> > > Is there a format document on the OpusTag structure?<br>
> > Search always<br>
> > >> shows<br>
> > >> > > up Vorbis but not Opus.<br>
> > >> ><br>
> > >> > The basic format is shared with Vorbis, but the 'magic<br>
> > signature' is<br>
> > >> > different ('OpusTags' instead of '0x05vorbis') and vorbis<br>
> > puts a 0x01<br>
> > >> > value in an extra byte after the last tag.<br>
> > >> ><br>
> > >> > The OpusTag packet layout is described in<br>
> > >> > <a href="https://tools.ietf.org/html/rfc7845.html#section-5.2" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc7845.html#section-5.2</a><br>
> > >> ><br>
> > >> > Common tag names used for interoperability are described in the<br>
> > >> Vorbis<br>
> > >> > documentation. See<br>
> > <a href="https://www.xiph.org/vorbis/doc/v-comment.html" rel="noreferrer" target="_blank">https://www.xiph.org/vorbis/doc/v-comment.html</a><br>
> > >> > There are more extensive tag lists on some other sites.<br>
> > >> ><br>
> > >> ><br>
> > >> ><br>
> > >> ><br>
> > >> > _______________________________________________<br>
> > >> > opus mailing list<br>
> > >> > <a href="mailto:opus@xiph.org">opus@xiph.org</a> <mailto:<a href="mailto:opus@xiph.org">opus@xiph.org</a>><br>
</div></div>> <mailto:<a href="mailto:opus@xiph.org">opus@xiph.org</a> <mailto:<a href="mailto:opus@xiph.org">opus@xiph.org</a>>><br>
> > >> > <a href="http://lists.xiph.org/mailman/listinfo/opus" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/opus</a><br>
> > >> ><br>
> > >><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
><br>
><br>
</blockquote></div><br></div>