Hello Jean-Marc, As an example, I am using the output of opus encoder to store the file as the following format and read back the same during decode process, without having much overhead. (Thought it would be useful to put a picture rather than running text) [image: Inline image 2] Regards Amit On Thu, May 12, 2016 at 10:47 AM, Amit Ashara <ashara.amit at gmail.com> wrote:> Hello Jean-Marc, > > 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 > > 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. > > 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. > > 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) > > Regards > Amit > > On Thu, May 12, 2016 at 9:58 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> > wrote: > >> On 05/12/2016 10:35 AM, Amit Ashara wrote: >> > 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. >> >> I'm not sure how you get a 7% overhead. In most uses I've seen, the >> overhead is more around 1%. >> >> > 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. >> >> CRCs should be a lot cheaper than the codec. >> >> > 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. >> >> If the only goal is to stream audio out... have you considered RTP? >> >> > 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... >> >> We do not force users to use any container. There are existing specs for >> using Opus inside Ogg, Matroska (WebM), MP4 and RTP. It will also fit in >> any other existing container. We just have no intention of creating new >> ones, though nothing prevents you from doing that. >> >> Cheers, >> >> Jean-Marc >> >> >> > Regards >> > Amit >> > >> > On Thu, May 12, 2016 at 7:17 AM, Jean-Marc Valin <jmvalin at jmvalin.ca >> > <mailto:jmvalin at jmvalin.ca>> wrote: >> > >> > The overhead of Ogg (in file size) is pretty small and it's >> efficient >> > enough for most applications (and uses far less CPU than the codec >> > anyway). If anything, you might want to look at optimizing the >> existing >> > Ogg implementation (e.g. like Tremor did in the context of Vorbis). >> > >> > Of course, you're always free to design a new container, but I doubt >> > it's worth it and it's a lot of work (e.g. you want your files to be >> > seekable, right?). The only thing I can assure you of is that we're >> not >> > going to bring a new "low-complexity" container to the IETF for >> > standardization. >> > >> > Cheers, >> > >> > Jean-Marc >> > >> > On 05/12/2016 07:37 AM, Amit Ashara wrote: >> > > Hello Ulrich, >> > > >> > > Putting some extra space is the not the reason for this request. >> It is >> > > the overhead of the frame v/s payload size. Basically larger the >> payload >> > > less % the overhead is (and that makes sense). However the >> complexity of >> > > implementing a read file structure where the file pointer has to >> go >> > > back-forth for reading the payload when multiple segments have to >> be >> > > read, CRC32 (something which needs to be done in SW) is going to >> > > increase the time the CPU shall spend in the encapsulation process >> > > rather than encoding/decoding process. >> > > >> > > The answer may be NO, but the question may still be asked. >> > > >> > > Regards >> > > Amit >> > > >> > > On Thu, May 12, 2016 at 1:29 AM, Ulrich Windl >> > > <Ulrich.Windl at rz.uni-regensburg.de >> > <mailto:Ulrich.Windl at rz.uni-regensburg.de> >> > > <mailto:Ulrich.Windl at rz.uni-regensburg.de >> > <mailto:Ulrich.Windl at rz.uni-regensburg.de>>> wrote: >> > > >> > > >>> Amit Ashara <ashara.amit at gmail.com <mailto: >> ashara.amit at gmail.com> >> > > <mailto:ashara.amit at gmail.com <mailto:ashara.amit at gmail.com >> >>> >> > schrieb am 11.05.2016 um 19:32 in >> > > Nachricht >> > > >> > < >> CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com >> > <mailto: >> CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com> >> > > >> > <mailto: >> CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com >> > <mailto: >> CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com>>>: >> > > > Hello Jean-Marc, >> > > > >> > > > So for the moment we can assume that this method is also OK >> to use? >> > > > >> > > > On Embedded Systems, both SRAM and Flash can be a >> restricting factor >> > > > besides the compute time. To optimize the utilization of >> embedded >> > > > resources, may I suggest a simplification of the Ogg-Opus >> format and can >> > > > this be considered by the Opus org and IETF as an addition? >> > > >> > > Why would you change the format if one encoder puts some >> extra space >> > > there? Does the spec forbid not to have that extra space? I >> haven't >> > > read it, but I'd be surprised it it were a MUST. If you want >> to add >> > > a MAY NOT, most implementers will object, I guess. >> > > >> > > > >> > > > Regards >> > > > Amit >> > > > >> > > > On Wed, May 11, 2016 at 12:09 PM, Jean-Marc Valin >> > > <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca> >> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>> >> > > > wrote: >> > > > >> > > >> On 05/11/2016 12:35 PM, Amit Ashara wrote: >> > > >> > I ran the opusenc.exe on a wave file and checked the >> OpusTag >> > > section. My >> > > >> > concern is on Total Segment Size being >> than the actual >> > data >> > > being >> > > >> > put. Is this just an example of implementation or does a >> size >> > > of 764 >> > > >> > BYTES kept as a place holder for putting more data? >> > > >> >> > > >> Yes, opusenc does reserve some space in the header so that >> > tags can >> > > >> later be modified "in place", without having to rewrite the >> > > entire file. >> > > >> >> > > >> Jean-Marc >> > > >> >> > > >> >> > > >> > 4f 67 67 53 = Oggs >> > > >> > 00 = Version >> > > >> > 00 = Header >> > > >> > 00 00 00 00 00 00 00 00 = Granule Position >> > > >> > a5 73 00 00 = Bit Stream Serial Number >> > > >> > 01 00 00 00 = Page Sequence Numner >> > > >> > 90 a9 36 42 = Checksum >> > > >> > 03 = Page Segments >> > > >> > ff ff fe = Each Segment Size (TOTAL SIZE IS 764 BYTES) >> > > >> > 4f 70 75 73 54 61 67 73 = OpusTags >> > > >> > 0b 00 00 00 = Vendor String Length of 11 >> > > >> > 6c 69 62 6f 70 75 73 20 31 2e 31 = "libopus 1.1" >> > > >> > 03 00 00 00 = User Comment List Length of 3 >> > > >> > 25 00 00 00 = User Comment #0 String Length of 37 >> > > >> > 45 4e 43 4f 44 45 52 3d 6f 70 75 73 65 6e 63 20 66 72 6f >> > 6d 20 >> > > 6f 70 75 >> > > >> > 73 2d 74 6f 6f 6c 73 20 30 2e 31 2e 39 = "ENCODER=opusenc >> > from >> > > >> > opus-tools 0.1.9" >> > > >> > 0a 00 00 00 = User Comment #1 String Length of 10 >> > > >> > 74 69 74 6c 65 3d 48 4f 4c 41 = "title=HOLA" >> > > >> > 1e 00 00 00 = User Comment #2 String Length of 30 >> > > >> > 45 4e 43 4f 44 45 52 5f 4f 50 54 49 4f 4e 53 3d 2d 2d 6d >> > 61 78 >> > > 2d 64 65 >> > > >> > 6c 61 79 20 32 30 = "ENCODER_OPTIONS=--max-delay 20" >> > > >> > 00 00 00... ALL THE WAY TO THE NEXT Oggs Container >> > > >> > >> > > >> > Regards >> > > >> > Amit >> > > >> > >> > > >> > On Tue, May 10, 2016 at 10:47 PM, Ralph Giles >> > > <giles at thaumas.net <mailto:giles at thaumas.net> >> > <mailto:giles at thaumas.net <mailto:giles at thaumas.net>> >> > > >> > <mailto:giles at thaumas.net <mailto:giles at thaumas.net> >> > <mailto:giles at thaumas.net <mailto:giles at thaumas.net>>>> wrote: >> > > >> > >> > > >> > On 10/05/16 02:37 PM, Amit Ashara wrote: >> > > >> > >> > > >> > > Is there a format document on the OpusTag >> structure? >> > > Search always >> > > >> shows >> > > >> > > up Vorbis but not Opus. >> > > >> > >> > > >> > The basic format is shared with Vorbis, but the >> 'magic >> > > signature' is >> > > >> > different ('OpusTags' instead of '0x05vorbis') and >> vorbis >> > > puts a 0x01 >> > > >> > value in an extra byte after the last tag. >> > > >> > >> > > >> > The OpusTag packet layout is described in >> > > >> > https://tools.ietf.org/html/rfc7845.html#section-5.2 >> > > >> > >> > > >> > Common tag names used for interoperability are >> described in the >> > > >> Vorbis >> > > >> > documentation. See >> > > https://www.xiph.org/vorbis/doc/v-comment.html >> > > >> > There are more extensive tag lists on some other >> sites. >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > _______________________________________________ >> > > >> > opus mailing list >> > > >> > opus at xiph.org <mailto:opus at xiph.org> >> > <mailto:opus at xiph.org <mailto:opus at xiph.org>> >> > > >> > http://lists.xiph.org/mailman/listinfo/opus >> > > >> > >> > > >> >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160512/e6cbce63/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 30140 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/opus/attachments/20160512/e6cbce63/attachment-0001.png>
The format you're describing here actually has *more* overhead than Ogg, not less. It's also unseakable, not robust errors, and without support for metadata. I'm not sure why you would want that. It's not like you're forced to include much data in the Ogg metadata (which seems to be the source of all the overhead you're seeing). Jean-Marc On 05/12/2016 11:51 AM, Amit Ashara wrote:> Hello Jean-Marc, > > As an example, I am using the output of opus encoder to store the file > as the following format and read back the same during decode process, > without having much overhead. (Thought it would be useful to put a > picture rather than running text) > > Inline image 2 > > Regards > Amit > > > On Thu, May 12, 2016 at 10:47 AM, Amit Ashara <ashara.amit at gmail.com > <mailto:ashara.amit at gmail.com>> wrote: > > Hello Jean-Marc, > > 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 > > 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. > > 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. > > 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) > > Regards > Amit > > On Thu, May 12, 2016 at 9:58 AM, Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > On 05/12/2016 10:35 AM, Amit Ashara wrote: > > 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. > > I'm not sure how you get a 7% overhead. In most uses I've seen, the > overhead is more around 1%. > > > 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. > > CRCs should be a lot cheaper than the codec. > > > 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. > > If the only goal is to stream audio out... have you considered RTP? > > > 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... > > We do not force users to use any container. There are existing > specs for > using Opus inside Ogg, Matroska (WebM), MP4 and RTP. It will > also fit in > any other existing container. We just have no intention of > creating new > ones, though nothing prevents you from doing that. > > Cheers, > > Jean-Marc > > > > Regards > > Amit > > > > On Thu, May 12, 2016 at 7:17 AM, Jean-Marc Valin <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca> > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>> wrote: > > > > The overhead of Ogg (in file size) is pretty small and > it's efficient > > enough for most applications (and uses far less CPU than > the codec > > anyway). If anything, you might want to look at optimizing > the existing > > Ogg implementation (e.g. like Tremor did in the context of > Vorbis). > > > > Of course, you're always free to design a new container, > but I doubt > > it's worth it and it's a lot of work (e.g. you want your > files to be > > seekable, right?). The only thing I can assure you of is > that we're not > > going to bring a new "low-complexity" container to the > IETF for > > standardization. > > > > Cheers, > > > > Jean-Marc > > > > On 05/12/2016 07:37 AM, Amit Ashara wrote: > > > Hello Ulrich, > > > > > > Putting some extra space is the not the reason for this > request. It is > > > the overhead of the frame v/s payload size. Basically > larger the payload > > > less % the overhead is (and that makes sense). However > the complexity of > > > implementing a read file structure where the file > pointer has to go > > > back-forth for reading the payload when multiple > segments have to be > > > read, CRC32 (something which needs to be done in SW) is > going to > > > increase the time the CPU shall spend in the > encapsulation process > > > rather than encoding/decoding process. > > > > > > The answer may be NO, but the question may still be asked. > > > > > > Regards > > > Amit > > > > > > On Thu, May 12, 2016 at 1:29 AM, Ulrich Windl > > > <Ulrich.Windl at rz.uni-regensburg.de > <mailto:Ulrich.Windl at rz.uni-regensburg.de> > > <mailto:Ulrich.Windl at rz.uni-regensburg.de > <mailto:Ulrich.Windl at rz.uni-regensburg.de>> > > > <mailto:Ulrich.Windl at rz.uni-regensburg.de > <mailto:Ulrich.Windl at rz.uni-regensburg.de> > > <mailto:Ulrich.Windl at rz.uni-regensburg.de > <mailto:Ulrich.Windl at rz.uni-regensburg.de>>>> wrote: > > > > > > >>> Amit Ashara <ashara.amit at gmail.com <mailto:ashara.amit at gmail.com> > <mailto:ashara.amit at gmail.com <mailto:ashara.amit at gmail.com>> > > > <mailto:ashara.amit at gmail.com > <mailto:ashara.amit at gmail.com> <mailto:ashara.amit at gmail.com > <mailto:ashara.amit at gmail.com>>>> > > schrieb am 11.05.2016 um 19:32 in > > > Nachricht > > > > > <CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com > <mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com> > > <mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com > <mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com>> > > > > > > <mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com > <mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com> > > <mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com > <mailto:CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com>>>>: > > > > Hello Jean-Marc, > > > > > > > > So for the moment we can assume that this method is also OK to use? > > > > > > > > On Embedded Systems, both SRAM and Flash can be a restricting factor > > > > besides the compute time. To optimize the utilization of embedded > > > > resources, may I suggest a simplification of the Ogg-Opus format and can > > > > this be considered by the Opus org and IETF as an addition? > > > > > > Why would you change the format if one encoder puts some extra space > > > there? Does the spec forbid not to have that extra space? I haven't > > > read it, but I'd be surprised it it were a MUST. If you want to add > > > a MAY NOT, most implementers will object, I guess. > > > > > > > > > > > Regards > > > > Amit > > > > > > > > On Wed, May 11, 2016 at 12:09 PM, Jean-Marc Valin > > > <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>> > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca> > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>> > > > > wrote: > > > > > > > >> On 05/11/2016 12:35 PM, Amit Ashara wrote: > > > >> > I ran the opusenc.exe on a wave file and > checked the OpusTag > > > section. My > > > >> > concern is on Total Segment Size being >> than > the actual > > data > > > being > > > >> > put. Is this just an example of implementation > or does a size > > > of 764 > > > >> > BYTES kept as a place holder for putting more data? > > > >> > > > >> Yes, opusenc does reserve some space in the > header so that > > tags can > > > >> later be modified "in place", without having to > rewrite the > > > entire file. > > > >> > > > >> Jean-Marc > > > >> > > > >> > > > >> > 4f 67 67 53 = Oggs > > > >> > 00 = Version > > > >> > 00 = Header > > > >> > 00 00 00 00 00 00 00 00 = Granule Position > > > >> > a5 73 00 00 = Bit Stream Serial Number > > > >> > 01 00 00 00 = Page Sequence Numner > > > >> > 90 a9 36 42 = Checksum > > > >> > 03 = Page Segments > > > >> > ff ff fe = Each Segment Size (TOTAL SIZE IS 764 > BYTES) > > > >> > 4f 70 75 73 54 61 67 73 = OpusTags > > > >> > 0b 00 00 00 = Vendor String Length of 11 > > > >> > 6c 69 62 6f 70 75 73 20 31 2e 31 = "libopus 1.1" > > > >> > 03 00 00 00 = User Comment List Length of 3 > > > >> > 25 00 00 00 = User Comment #0 String Length of 37 > > > >> > 45 4e 43 4f 44 45 52 3d 6f 70 75 73 65 6e 63 20 > 66 72 6f > > 6d 20 > > > 6f 70 75 > > > >> > 73 2d 74 6f 6f 6c 73 20 30 2e 31 2e 39 > "ENCODER=opusenc > > from > > > >> > opus-tools 0.1.9" > > > >> > 0a 00 00 00 = User Comment #1 String Length of 10 > > > >> > 74 69 74 6c 65 3d 48 4f 4c 41 = "title=HOLA" > > > >> > 1e 00 00 00 = User Comment #2 String Length of 30 > > > >> > 45 4e 43 4f 44 45 52 5f 4f 50 54 49 4f 4e 53 3d > 2d 2d 6d > > 61 78 > > > 2d 64 65 > > > >> > 6c 61 79 20 32 30 > "ENCODER_OPTIONS=--max-delay 20" > > > >> > 00 00 00... ALL THE WAY TO THE NEXT Oggs Container > > > >> > > > > >> > Regards > > > >> > Amit > > > >> > > > > >> > On Tue, May 10, 2016 at 10:47 PM, Ralph Giles > > > <giles at thaumas.net <mailto:giles at thaumas.net> > <mailto:giles at thaumas.net <mailto:giles at thaumas.net>> > > <mailto:giles at thaumas.net <mailto:giles at thaumas.net> > <mailto:giles at thaumas.net <mailto:giles at thaumas.net>>> > > > >> > <mailto:giles at thaumas.net > <mailto:giles at thaumas.net> <mailto:giles at thaumas.net > <mailto:giles at thaumas.net>> > > <mailto:giles at thaumas.net <mailto:giles at thaumas.net> > <mailto:giles at thaumas.net <mailto:giles at thaumas.net>>>>> wrote: > > > >> > > > > >> > On 10/05/16 02:37 PM, Amit Ashara wrote: > > > >> > > > > >> > > Is there a format document on the OpusTag > structure? > > > Search always > > > >> shows > > > >> > > up Vorbis but not Opus. > > > >> > > > > >> > The basic format is shared with Vorbis, but > the 'magic > > > signature' is > > > >> > different ('OpusTags' instead of > '0x05vorbis') and vorbis > > > puts a 0x01 > > > >> > value in an extra byte after the last tag. > > > >> > > > > >> > The OpusTag packet layout is described in > > > >> > > https://tools.ietf.org/html/rfc7845.html#section-5.2 > > > >> > > > > >> > Common tag names used for interoperability > are described in the > > > >> Vorbis > > > >> > documentation. See > > > https://www.xiph.org/vorbis/doc/v-comment.html > > > >> > There are more extensive tag lists on some > other sites. > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > _______________________________________________ > > > >> > opus mailing list > > > >> > opus at xiph.org <mailto:opus at xiph.org> > <mailto:opus at xiph.org <mailto:opus at xiph.org>> > > <mailto:opus at xiph.org <mailto:opus at xiph.org> > <mailto:opus at xiph.org <mailto:opus at xiph.org>>> > > > >> > http://lists.xiph.org/mailman/listinfo/opus > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > >
Hello Jean-Marc The format you're describing here actually has *more* overhead than Ogg not less.>> Not for a single opus encoded frame.It's also unseakable, not robust errors, and without support for metadata.>> As I mentioned earlier "At the same time the file processing complexityis 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 (sound clips like the one on mouse click, or swoosh sounds on HMI panels) to be played. A custom container is OK," I'm not sure why you would want that. It's not like you're forced to include much data in the Ogg metadata (which seems to be the source of all the overhead you're seeing).>> It took me the day to implement a Ogg/Opus file parser. This addedalmost 11KB of more program memory (had to make skips for a lot of the header fields like sequence and CRC checks as the on-chip flash is limited on uC) The whole point of the discussion was to open the possibility of a lite version of the Ogg/Opus which would be more suitable for uC's. Please do consider this discussion. Regards Amit On Thu, May 12, 2016 at 9:40 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote:> The format you're describing here actually has *more* overhead than Ogg, > not less. It's also unseakable, not robust errors, and without support > for metadata. I'm not sure why you would want that. It's not like you're > forced to include much data in the Ogg metadata (which seems to be the > source of all the overhead you're seeing). > > Jean-Marc > > On 05/12/2016 11:51 AM, Amit Ashara wrote: > > Hello Jean-Marc, > > > > As an example, I am using the output of opus encoder to store the file > > as the following format and read back the same during decode process, > > without having much overhead. (Thought it would be useful to put a > > picture rather than running text) > > > > Inline image 2 > > > > Regards > > Amit > > > > > > On Thu, May 12, 2016 at 10:47 AM, Amit Ashara <ashara.amit at gmail.com > > <mailto:ashara.amit at gmail.com>> wrote: > > > > Hello Jean-Marc, > > > > 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 > > > > 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. > > > > 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. > > > > 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) > > > > Regards > > Amit > > > > On Thu, May 12, 2016 at 9:58 AM, Jean-Marc Valin <jmvalin at jmvalin.ca > > <mailto:jmvalin at jmvalin.ca>> wrote: > > > > On 05/12/2016 10:35 AM, Amit Ashara wrote: > > > 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. > > > > I'm not sure how you get a 7% overhead. In most uses I've seen, > the > > overhead is more around 1%. > > > > > 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. > > > > CRCs should be a lot cheaper than the codec. > > > > > 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. > > > > If the only goal is to stream audio out... have you considered > RTP? > > > > > 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... > > > > We do not force users to use any container. There are existing > > specs for > > using Opus inside Ogg, Matroska (WebM), MP4 and RTP. It will > > also fit in > > any other existing container. We just have no intention of > > creating new > > ones, though nothing prevents you from doing that. > > > > Cheers, > > > > Jean-Marc > > > > > > > Regards > > > Amit > > > > > > On Thu, May 12, 2016 at 7:17 AM, Jean-Marc Valin < > jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca> > > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>> > wrote: > > > > > > The overhead of Ogg (in file size) is pretty small and > > it's efficient > > > enough for most applications (and uses far less CPU than > > the codec > > > anyway). If anything, you might want to look at optimizing > > the existing > > > Ogg implementation (e.g. like Tremor did in the context of > > Vorbis). > > > > > > Of course, you're always free to design a new container, > > but I doubt > > > it's worth it and it's a lot of work (e.g. you want your > > files to be > > > seekable, right?). The only thing I can assure you of is > > that we're not > > > going to bring a new "low-complexity" container to the > > IETF for > > > standardization. > > > > > > Cheers, > > > > > > Jean-Marc > > > > > > On 05/12/2016 07:37 AM, Amit Ashara wrote: > > > > Hello Ulrich, > > > > > > > > Putting some extra space is the not the reason for this > > request. It is > > > > the overhead of the frame v/s payload size. Basically > > larger the payload > > > > less % the overhead is (and that makes sense). However > > the complexity of > > > > implementing a read file structure where the file > > pointer has to go > > > > back-forth for reading the payload when multiple > > segments have to be > > > > read, CRC32 (something which needs to be done in SW) is > > going to > > > > increase the time the CPU shall spend in the > > encapsulation process > > > > rather than encoding/decoding process. > > > > > > > > The answer may be NO, but the question may still be > asked. > > > > > > > > Regards > > > > Amit > > > > > > > > On Thu, May 12, 2016 at 1:29 AM, Ulrich Windl > > > > <Ulrich.Windl at rz.uni-regensburg.de > > <mailto:Ulrich.Windl at rz.uni-regensburg.de> > > > <mailto:Ulrich.Windl at rz.uni-regensburg.de > > <mailto:Ulrich.Windl at rz.uni-regensburg.de>> > > > > <mailto:Ulrich.Windl at rz.uni-regensburg.de > > <mailto:Ulrich.Windl at rz.uni-regensburg.de> > > > <mailto:Ulrich.Windl at rz.uni-regensburg.de > > <mailto:Ulrich.Windl at rz.uni-regensburg.de>>>> wrote: > > > > > > > > >>> Amit Ashara <ashara.amit at gmail.com <mailto: > ashara.amit at gmail.com> > > <mailto:ashara.amit at gmail.com <mailto:ashara.amit at gmail.com>> > > > > <mailto:ashara.amit at gmail.com > > <mailto:ashara.amit at gmail.com> <mailto:ashara.amit at gmail.com > > <mailto:ashara.amit at gmail.com>>>> > > > schrieb am 11.05.2016 um 19:32 in > > > > Nachricht > > > > > > > < > CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com > > <mailto: > CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com> > > > <mailto: > CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com > > <mailto: > CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com>> > > > > > > > > > <mailto: > CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com > > <mailto: > CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com> > > > <mailto: > CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com > > <mailto: > CAEyg9sjvTWMBMMCJ8HQcYmbv1BtNt54CgpqWaGNm02MWrKcxaQ at mail.gmail.com>>>>: > > > > > Hello Jean-Marc, > > > > > > > > > > So for the moment we can assume that this method > is also OK to use? > > > > > > > > > > On Embedded Systems, both SRAM and Flash can be a > restricting factor > > > > > besides the compute time. To optimize the > utilization of embedded > > > > > resources, may I suggest a simplification of the > Ogg-Opus format and can > > > > > this be considered by the Opus org and IETF as an > addition? > > > > > > > > Why would you change the format if one encoder puts > some extra space > > > > there? Does the spec forbid not to have that extra > space? I haven't > > > > read it, but I'd be surprised it it were a MUST. If > you want to add > > > > a MAY NOT, most implementers will object, I guess. > > > > > > > > > > > > > > Regards > > > > > Amit > > > > > > > > > > On Wed, May 11, 2016 at 12:09 PM, Jean-Marc Valin > > > > <jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca> > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>> > > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca> > > <mailto:jmvalin at jmvalin.ca <mailto:jmvalin at jmvalin.ca>>>> > > > > > wrote: > > > > > > > > > >> On 05/11/2016 12:35 PM, Amit Ashara wrote: > > > > >> > I ran the opusenc.exe on a wave file and > > checked the OpusTag > > > > section. My > > > > >> > concern is on Total Segment Size being >> than > > the actual > > > data > > > > being > > > > >> > put. Is this just an example of implementation > > or does a size > > > > of 764 > > > > >> > BYTES kept as a place holder for putting more > data? > > > > >> > > > > >> Yes, opusenc does reserve some space in the > > header so that > > > tags can > > > > >> later be modified "in place", without having to > > rewrite the > > > > entire file. > > > > >> > > > > >> Jean-Marc > > > > >> > > > > >> > > > > >> > 4f 67 67 53 = Oggs > > > > >> > 00 = Version > > > > >> > 00 = Header > > > > >> > 00 00 00 00 00 00 00 00 = Granule Position > > > > >> > a5 73 00 00 = Bit Stream Serial Number > > > > >> > 01 00 00 00 = Page Sequence Numner > > > > >> > 90 a9 36 42 = Checksum > > > > >> > 03 = Page Segments > > > > >> > ff ff fe = Each Segment Size (TOTAL SIZE IS 764 > > BYTES) > > > > >> > 4f 70 75 73 54 61 67 73 = OpusTags > > > > >> > 0b 00 00 00 = Vendor String Length of 11 > > > > >> > 6c 69 62 6f 70 75 73 20 31 2e 31 = "libopus 1.1" > > > > >> > 03 00 00 00 = User Comment List Length of 3 > > > > >> > 25 00 00 00 = User Comment #0 String Length of > 37 > > > > >> > 45 4e 43 4f 44 45 52 3d 6f 70 75 73 65 6e 63 20 > > 66 72 6f > > > 6d 20 > > > > 6f 70 75 > > > > >> > 73 2d 74 6f 6f 6c 73 20 30 2e 31 2e 39 > > "ENCODER=opusenc > > > from > > > > >> > opus-tools 0.1.9" > > > > >> > 0a 00 00 00 = User Comment #1 String Length of > 10 > > > > >> > 74 69 74 6c 65 3d 48 4f 4c 41 = "title=HOLA" > > > > >> > 1e 00 00 00 = User Comment #2 String Length of > 30 > > > > >> > 45 4e 43 4f 44 45 52 5f 4f 50 54 49 4f 4e 53 3d > > 2d 2d 6d > > > 61 78 > > > > 2d 64 65 > > > > >> > 6c 61 79 20 32 30 > > "ENCODER_OPTIONS=--max-delay 20" > > > > >> > 00 00 00... ALL THE WAY TO THE NEXT Oggs > Container > > > > >> > > > > > >> > Regards > > > > >> > Amit > > > > >> > > > > > >> > On Tue, May 10, 2016 at 10:47 PM, Ralph Giles > > > > <giles at thaumas.net <mailto:giles at thaumas.net> > > <mailto:giles at thaumas.net <mailto:giles at thaumas.net>> > > > <mailto:giles at thaumas.net <mailto:giles at thaumas.net> > > <mailto:giles at thaumas.net <mailto:giles at thaumas.net>>> > > > > >> > <mailto:giles at thaumas.net > > <mailto:giles at thaumas.net> <mailto:giles at thaumas.net > > <mailto:giles at thaumas.net>> > > > <mailto:giles at thaumas.net <mailto:giles at thaumas.net> > > <mailto:giles at thaumas.net <mailto:giles at thaumas.net>>>>> wrote: > > > > >> > > > > > >> > On 10/05/16 02:37 PM, Amit Ashara wrote: > > > > >> > > > > > >> > > Is there a format document on the OpusTag > > structure? > > > > Search always > > > > >> shows > > > > >> > > up Vorbis but not Opus. > > > > >> > > > > > >> > The basic format is shared with Vorbis, but > > the 'magic > > > > signature' is > > > > >> > different ('OpusTags' instead of > > '0x05vorbis') and vorbis > > > > puts a 0x01 > > > > >> > value in an extra byte after the last tag. > > > > >> > > > > > >> > The OpusTag packet layout is described in > > > > >> > > > https://tools.ietf.org/html/rfc7845.html#section-5.2 > > > > >> > > > > > >> > Common tag names used for interoperability > > are described in the > > > > >> Vorbis > > > > >> > documentation. See > > > > https://www.xiph.org/vorbis/doc/v-comment.html > > > > >> > There are more extensive tag lists on some > > other sites. > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > _______________________________________________ > > > > >> > opus mailing list > > > > >> > opus at xiph.org <mailto:opus at xiph.org> > > <mailto:opus at xiph.org <mailto:opus at xiph.org>> > > > <mailto:opus at xiph.org <mailto:opus at xiph.org> > > <mailto:opus at xiph.org <mailto:opus at xiph.org>>> > > > > >> > http://lists.xiph.org/mailman/listinfo/opus > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160512/e14bae19/attachment-0001.html>