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>> 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 > http://lists.xiph.org/mailman/listinfo/opus >
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? Regards Amit On Wed, May 11, 2016 at 12:09 PM, Jean-Marc Valin <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>> 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 > > http://lists.xiph.org/mailman/listinfo/opus > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160511/b3463aad/attachment.html>
Hi Amit, I'm not sure what you're trying to ask, but the reserved space in the header is an optional thing. Encoders are free to do it, but are not required to do so. Jean-Marc On 05/11/2016 01:32 PM, Amit Ashara wrote:> 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? > > Regards > Amit > > On Wed, May 11, 2016 at 12:09 PM, Jean-Marc Valin <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>>> 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> > > http://lists.xiph.org/mailman/listinfo/opus > > > >
>>> Amit Ashara <ashara.amit at gmail.com> schrieb am 11.05.2016 um 19:32 in Nachricht<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> > 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>> 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 >> > http://lists.xiph.org/mailman/listinfo/opus >> > >>