similar to: Fwd: [payload] RFC 7587 on RTP Payload Format for the Opus Speech and Audio Codec

Hi there, Im trying to understand the structure of an opus UDP payload. Recently i capture a test audio containing opus codec. I notice that some packets contains the same number of payload block.(e.g.58 bytes) When i look at the UDP data i see the first few four bytes were having these hex representation, 0x0d 0x80 0x5d 0xeb Can someone explain to me the meaning of the first four bytes in the

Dear Christian van Bijleveld, You can use any of the below DSPs of Texas Instruments 1. TMS320C674x - This supports floating point implementation of opus 2. TMS320C66x - This supports both floating and fixed point implementations 3. TMS320C64x - This supports only fixed point implementation Regards, Mahantesh On Mon, May 13, 2013 at 10:12 PM, <opus-request at xiph.org> wrote: >

Hello All When sending the Opus Packet in RTP Payload, the compressed frame is the output of the encoder? Also the config value as given in the RFC6716, 16...19 | CELT-only | NB | 2.5, 5, 10, 20 ms 16 corresponds to 2.5 ms 17 corresponds to 5 ms 18 corresponds to 10 ms 19 corresponds to 20 ms Is this correct representation of the data? Also in the RFC3551 the payload

Hi, some good news from IETF :) /alfred -------------- next part -------------- An embedded message was scrubbed... From: The IESG <iesg-secretary at ietf.org> Subject: [AVT] Protocol Action: 'RTP Payload Format for the Speex Codec' to Proposed Standard Date: Mon, 18 May 2009 06:26:11 -0700 (PDT) Size: 3867 Url:

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, rfc-editor at

We want to push for an open and standards compliant system for all multimedia. We've done a good job on the interoperability side with icecast and MP3. We're making a ton of progress with the Vorbis codec as well, which will allow us to do many things we weren't able to do before. It's time to start thinking about RTSP, RTP, Multicast and all of the other standards and features.

Hi Jack, > You're comments are welcome. Here they are... 3.1 RTP Header Payload Type (PT): I don't see an alternative to using a value of the dynamic range (96-127). IIRC, other ranger are reserved for fixed values assigned by IETF. "A dynamic payload type MUST be used - i.e., one in the range [96,127]." 3.2 Payload Header If you refer to RFC2119, please keep the capital

(hello all, this is my first writing. so please bear with me if I'm wrong anywhere.) orry to break too lately, but how is the RTP payload submission is going? could we see the new payload at March IETF? I agree that it would be fairy straightforward to make an RTP payload for ogg vorbis, assuming raw packets, AFAIK. using physical bitstream is, in this case, not adequate by the reasons in

Hi, (moving back to the list as some bits can be useful to everyone) > I am sure that 75 is the length of payload only. Confirmed > I also don't have idea for the package containing data of a length 46. > > To make everything more clear, Payload type in rtp packages is 97. > SDP defines the stream as > a=rtpmap: 97 SPEEX/8000 That's a dynamic payload number, so it

Not sure what a payload of 75 bytes could be. Are you sure that doesn't include the 12-byte RTP header? Other than that, maybe it's using wideband (although there's nothing that corresponds exactly to 75 bytes. If you send me the hexdump for one packet, I may be able to find out what it is. Jean-Marc Pawel Cyrta wrote: > Hello to all speex developers, > > I have question

Yes, regarding the unsigned to signed conversion you are right, it is implementation defined. I just had an issue a couple of years ago with a compiler which incorrectly treated unsigned overflow as undefined rather than implementation defined? Regarding the 64 bit profiling: I looked at the disassembly (gcc ?c ?S ?O2 ../opus/silk/sum_sqr_shift.c ?I../opus/include ?I../opus/celt) of the 64 bit

Hello to all speex developers, I have question regarding payload length of narrowband speex in RTP. I were watching tcpdump of the xlite softphone and have found that it uses weird payload length namely 75 Bytes I went through various source and without success. To be clear: For 8000Hz sample in 20 ms that is 160 samples per frame. This makes 50 frames per sec. modes bit-rate 8 kbit/s

Congrats JM. You certainly deserved to get the payload format approved. If I'm not being too much of a pest, I was wondering how close Speex 1.2 is to being a full-fledged release. I know that your focus these days is on CELT (and I'm glad for that) but I was wondering if you had any plans for any real changes or fixes to Speex in the near term. For my project I make a lot of changes

Hi everyone, After years of effort, the Speex RTP payload format is now approved as an RFC: http://www.rfc-editor.org/rfc/rfc5574.txt Many thanks to everyone who participated. Enjoy! Jean-Marc

Hi everyone, After years of effort, the Speex RTP payload format is now approved as an RFC: http://www.rfc-editor.org/rfc/rfc5574.txt Many thanks to everyone who participated. Enjoy! Jean-Marc

Hi Folks, thanks for the great work, not sure if this is the right list for this type of quesiton. We are looking to use only Opus as "one codec for all", with VoIP-out obviously we want to tune it. I am planning to use fmtp in SDP to control server/client Opus settings. Something like : - *maxplaybackrate*: a hint about the maximum output sampling rate that the receiver is

Dear Opus developers. This is the first time I write here, so hello to everybody! Sorry to disturb you but I would like to ask you something I could not answer by googling and by looking at this mailing list archive. I have just started investigating this new and promising codec for real-time audio transport over the internet for industrial applications. I was previously experimenting with RTP

http://www.xiph.org/ogg/vorbis/doc/draft-moffitt-vorbis-rtp-00.txt This is the Internet-Draft I'll be submitting tomorrow and hopefully presenting at the March IETF meeting. If you see anything major, let me know right away, I'll be submitting this in the morning. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To

Hi, I have a few questions/remarks about the draft, in particular about the SDP usage of Speex (section 5): - Which samplerate should be used if you receive something like m=3Daudio 8008 RTP/AVP 97 a=3Drtpmap:97 speex/8000 a=3Dfmtp:97 sr=3D16000;ebw=3Dultra - There is an inconsistency in the description of the 'penh'parameter. According to the description,

Hello to all speex developers, I have question regarding payload length of narrowband speex in RTP. I were watching tcpdump of the xlite softphone and have found that it uses weird payload length namely 75 Bytes I went through various source and without success. To be clear: For 8000Hz sample in 20 ms that is 160 samples per frame. This makes 50 frames per sec. modes bit-rate 8 kbit/s