<div dir="ltr"><div><div>Hello Jean-Marc,<br><br></div><div>I suspected the answer to be No.<br><br></div><div>For HMI panels, except for the capture pattern and a single page segment entry, other fields are not important, and which results in almost 7% overhead for a 20ms raw frame encoded with Opus. At the same time the file processing complexity is way too less considering that CRC's do not not need to be considered (programmer pods ensure that) and neither is seek as these are definite streams to be played. A custom container is OK, but my suspicion is it may spawn more containers as embedded uC mostly have less than 1MB on chip flash and less than 256KB on chip RAM and most of the uC are executing under 100MHz, with processing more towards control and communication.<br><br></div><div>I like Opus codec, but I wanted to make sure that the Opus org does hear the argument for a simpler (lite container) which is spec'ed and makes tool development standard. This also gives the options to embedded developers to use the lite container or full Ogg container based on the requirement, rather than forcing users to Ogg for simple devices...<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 7:17 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">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>
<span class=""><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>
</span><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><br>
</span>> <mailto:<a href="mailto:ashara.amit@gmail.com">ashara.amit@gmail.com</a>>> schrieb am 11.05.2016 um 19:32 in<br>
> Nachricht<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>
<span class="">> > 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>
</span>> <<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 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 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 6d 20<br>
> 6f 70 75<br>
> >> > 73 2d 74 6f 6f 6c 73 20 30 2e 31 2e 39 = "ENCODER=opusenc 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 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>
</div></div><span class="">> >> > <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>
</span>> >> > <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>
</blockquote></div><br></div>