search for: rfc7845

...-> <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'> <!ENTITY rfc7845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7845.xml'> ]> <?rfc toc="yes" symrefs="yes" ?> <rfc ipr="trust200902" category="std" docName="draft-graczyk-opus-ambisonics" updates="7845"...

...l Mapping Family > 254 SHOULD interpret the Opus stream as containing ambisonics with the > format described in Section 3.1." > > Aside from changing 254 to 2, the "SHOULD" should be a "MUST". Changed to "MUST". I used SHOULD because that is what is in RFC7845 5.1.1.4. I reasoned that if an implementation were allowed to treat mapping family 2 its own way (based on the language in 5.1.1.4), then I shouldn't change that behavior. It makes sense to make this strict though. > Section 3.1: "Allowed numbers of channels: (1 + l)^2 for l = 0...14&q...

Tim, Would you mind giving me a more specific example of the sort of document that you think this should look like? I'd like to write up something that is somewhat final. On Mon, May 2, 2016 at 9:30 PM, Michael Graczyk <mgraczyk at google.com> wrote: > On Fri, Apr 29, 2016 at 4:32 PM, Timothy B. Terriberry > <tterribe at xiph.org> wrote: > > As a general point,

FYI, the Ogg Opus encapsulation is now RFC 7845: https://tools.ietf.org/html/rfc7845 -------- Forwarded Message -------- Subject: [codec] RFC 7845 on Ogg Encapsulation for the Opus Audio Codec Date: Fri, 29 Apr 2016 19:47:28 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: drafts-update-ref at iana.org, codec at ietf.org,...

Thanks for the input! --Albin On Sat, May 12, 2018 at 6:00 PM, Orestes Zoupanos <oresteszoupanos at hotmail.com> wrote: > Hi Albin! > > There may be some details at: https://tools.ietf.org/html/rfc7845#section-6 > > Otherwise, I hope someone else on this list might be able to give a better > formula for estimating packet size. > > Regards, > > Orestes > > On 12/05/2018 16:31, Albin Stigö wrote: > > Hello, > > I'm working on an Opus encoder block for GNUr...

...:12 AM, Drew Allen wrote: > > We assume that the input file is ordered first by ACN ambisonic channels > > followed by a (possible) stereo track, and we want to swap the order for > > the API in order to couple the stereo for coding. > > Well, if you look at section 5.1.1 of RFC7845: > > The 'coupled stream > count' field indicates that the decoders for the first M Opus > streams are to be initialized for stereo (two-channel) output, > and the remaining (N - M) decoders are to be initialized for mono > (a single chan...

...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. -------------- next part -------------- A non-text attachment was scrubbed... Name: sig...

Hello, I'm working on an Opus encoder block for GNUradio (a signal processing toolkit). I was wondering if there's some formula/heuristic for estimating the packet size average case / worst case given a certain encoder setting (assuming VBR). I need to provided a reasonable estimate to the GNUradio memory allocator. --Albin

Hello all, I may have asked this previously, but I am still on a mission to get metadata on my OPUS streams (FLAC if possible also). I am using IceCast v2.4.4 (on Windows 8.1) and RadioCaster as an encoder for OPUS streams and I know that sending the streams directly to IceCast will not pass metadata for song title and artist. I have tried using a built-in server in RadioCaster and I can see

...s 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. > > > > > ___________________________...

...m> wrote: >> Thanks for the input! >> >> --Albin >> >> On Sat, May 12, 2018 at 6:00 PM, Orestes Zoupanos >> <oresteszoupanos at hotmail.com> wrote: >>> Hi Albin! >>> >>> There may be some details at: https://tools.ietf.org/html/rfc7845#section-6 >>> >>> Otherwise, I hope someone else on this list might be able to give a better >>> formula for estimating packet size. >>> >>> Regards, >>> >>> Orestes >>> >>> On 12/05/2018 16:31, Albin Stigö wrote: >...

Hi, I have application, where I am reciving the RTP packets, which has OPUS payload. >From the RTP packets I got following information: (12 byes Header) tells about the version, payload time, time stamp, srsc, etc. The rest of the packet is OPUS payload (raw format), The TOC byte from OPUS payload tells its 20ms frame, even the time stamp different of 960 means 20 msec frame. Questions: 1)

...nature' 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. >> &...

...largely a description of ffmpeg's libswresample's behavior. Documenting some downmixing behavior was suggested by mark4o in the #opus channel on Freenode; not sure if the current formatting is optimal. I'm referring to (and using terminology from) the struct defined in section 5.1.1 of RFC7845. Should I copy the relevant portions into this document as well? I'm redefining the mapping table for this mapping family. This was an easy place to specify channel positions, but it means that the "multiple channels copied from the same stream" feature isn't available. I don'...

...nature' 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. > > >...

Hi Jean-Marc, Thanks again for your comments. Attached is a revised patch. On Mon, Apr 24, 2017 at 1:08 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I think your revised patch looks good overall. Just two comments: > > 1) In opus_multistream_encoder_init_impl(), rather than use a huge > condition with two ORs for the return OPUS_BAD_ARG, maybe you can

...he 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. > > -------------- next part -------------- An HTML attachment...

...edia container. Such files use the '.opus' filename extension. There's some rough example code for this in the opus-tools package. See for example https://git.xiph.org/?p=opus-tools.git;f=src/opusrtp.c;hb=HEAD#l103 This disk and stream format is specified in https://tools.ietf.org/html/rfc7845.html > 3) is there any information OPUS payload has(except TOC(first byte))??? The first several bytes define how the audio is split into frames, the duration, audio bandwidth, and the coding mode. This is described in https://tools.ietf.org/html/rfc6716#section-3.1 > 4) I have RAW opus p...

On 25/04/17 10:12 AM, Drew Allen wrote: > We assume that the input file is ordered first by ACN ambisonic channels > followed by a (possible) stereo track, and we want to swap the order for > the API in order to couple the stereo for coding. Well, if you look at section 5.1.1 of RFC7845: The 'coupled stream count' field indicates that the decoders for the first M Opus streams are to be initialized for stereo (two-channel) output, and the remaining (N - M) decoders are to be initialized for mono (a single channel) only. In other words, i...

...> We assume that the input file is ordered first by ACN ambisonic > channels > > followed by a (possible) stereo track, and we want to swap the > order for > > the API in order to couple the stereo for coding. > > Well, if you look at section 5.1.1 of RFC7845: > > The 'coupled stream > count' field indicates that the decoders for the first M Opus > streams are to be initialized for stereo (two-channel) output, > and the remaining (N - M) decoders are to be initialized for mono >...