[opus] Ogg Format
Amit Ashara
ashara.amit at gmail.com
Thu May 12 15:47:37 UTC 2016
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/b6a0ad67/attachment-0001.html>
More information about the opus
mailing list