similar to: RTP payload

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

FYI, the Opus RTP payload format is now RFC7587: https://tools.ietf.org/html/rfc7587 Cheers, Jean-Marc -------- Forwarded Message -------- Subject: [payload] RFC 7587 on RTP Payload Format for the Opus Speech and Audio Codec Date: Tue, 30 Jun 2015 16:33:17 -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

hmm...forgive my ignorance here. icould have explained it wrong. the rtp header has the pt (payload) field as a 7 bit value. i was under the impression speex had a particular value i should set it to. is this so? if no what value should i assign it, whether by convention or otherwise? Note that i'm implementing a simple rtp header and combining it with the speex payload i'm not using

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 Jean-Marc, 1. Why CELT versus Speex? 2. What's the RTP payload for CELT, so we can add it in Yate? 3. What are the SDP declaration parameters? Diana Jean-Marc Valin wrote: > Hi everyone, > > I'm happy to announce CELT version 0.5.0. This release includes > simplifications to the bit allocation code and includes a new > low-complexity mode that can be enabled (without

On Thu, 16 Oct 2008, Jean-Marc Valin wrote: > Aymeric Moizard a ?crit : >>> None of that is defined yet, though I'm open to suggestions on how to do >>> the mapping. >> >> CELT/44100 and CELT/48000 >> a=fmtp:105 stereo=on >> >> probably a latency value? > > It would definitely need a frame_size value > >> "CELT"

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

if the new draft in the manual is used. I don't find how to tell the decoder which mode(NB/WB/UWB) is used in the encoder. The RTP header don't contain the mode field and I don't find the mode information in the coded frame either. Does this mean we have to use NB decoder in all cases? Lianghu On 11/22/06, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > >

The latest revision of the draft RTP Profile is attached for review. This will be submitted to the IETF Audio-Video Transport Working Group for consideration immediately, so if you have any more comments, let us know. In addition, we will be applying for an official MIME type. Note that the AVP code and the MIME type in this latest revision have been changed from "SPX" to

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

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

Hi everyone, I'm happy to announce CELT version 0.5.0. This release includes simplifications to the bit allocation code and includes a new low-complexity mode that can be enabled (without breaking compatibility) on the encoder side. There are several other optimisations and bug fixes included. The API has also been slightly modified, so code using CELT will have to be updated (only minor

Hi everyone, I'm happy to announce CELT version 0.5.0. This release includes simplifications to the bit allocation code and includes a new low-complexity mode that can be enabled (without breaking compatibility) on the encoder side. There are several other optimisations and bug fixes included. The API has also been slightly modified, so code using CELT will have to be updated (only minor

Hi all, Please find below an updated Speex Internet Draft document. It would be good if we could book some time for discussion on Speex at the IETF meeting in Vienna (scheduled for 14th July). The cutoff for submission is 9:00am EDT, (GMT -04:00), 30th June. Comments and feedback welcomed! Regards Phil

On Tue, 14 Oct 2008, Jean-Marc Valin wrote: > Diana Cionoiu a ?crit : >> Hi Jean-Marc, >> >> 1. Why CELT versus Speex? > > There's nearly no overlap between Speex and CELT. CELT is much higher > quality, very low latency, and of course, higher bit-rate than Speex. So > it really depends on the application. > >> 2. What's the RTP payload for CELT,

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

I'm currently implementing A rtp header info and using speex for audio. can someone tell me what the rtp payload type value is for speex. i've checked the submitted speex draft and it says its beyond its scope and i can't find anything in RFC3550 that might suggest what it is. any help would be appreciated thank you, Greg --------------------------------- Boardwalk for $500?

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

There's a field in the SDP description for narrowband/wideband/ultrawideband. Jean-Marc lianghu xu wrote: > if the new draft in the manual is used. I don't find how to tell the > decoder which mode(NB/WB/UWB) is used > in the encoder. The RTP header don't contain the mode field and I don't > find the mode information in the > coded frame either. > >