similar to: First draft for Speex RTP profile - Please send your comments

Hi, We'd like to announce the first draft for the Speex RTP profile. It was written essentially by Greg Herlein, with some help from Simon Morlat and I. We'd like to get some feedback on it before it is sent to the IETF. Basically this will allow all SIP based VoIP applications using Speex to inter-operate. For those interested, there's already Simon's LinPhone (www.linphone.org)

(sent on behalf of Federico Montesino Pouzols <fedemp@altern.org>) Hi, I like the draft, particularly because of its simplicity, which is another pro of speex compared with other codecs. Some comments: <p> - Reading section 3, I understand that frames cannot be fragmented across different RTP packets, which seems quite reasonable. I think a explicit statement on this

Ohh... Nice! This is new in 1.0.1, isn't it? It doesn't seem to be included in the reference manual yet, though. Thanks! Tom <p>Jean-Marc Valin (jean-marc.valin@hermes.usherb.ca) wrote: > > OK, this is how it works: > > The encoder calls speex_encode any number of times and then calls > speex_bits_insert_terminator before sending the bits. > > The

Ok, I figured it out. :) This seems to work: 1) Call speex_bits_read_from() once, specifying the location in memory of the compressed data, and the total length of that data. 2) Keep calling speex_decode() until speex_bits_remaining() returns 0. Then you don't have to keep track of the # of frames per packet, or the size of each compressed frame. It's done magically by the codec.

Hi, I have a question about section 3.4 of the RTP payload draft: > Speex codecs [11] are able to detect the the bitrate from the > payload and are responsible for detecting the 20 msec boundaries > between each frame. This suggests that you can encode some frames with Speex, pass the compressed bits to the decoder, and you'll get the output - without having to do external

> The RTP payload MUST be padded to provide an integer number of > octets as the payload length. These padding bits MUST be all zero. > This padding is only required for the last frame in the packet, and > only to ensure the packet contents ends on an octet boundary. AFAIK the padding changed with the latest draft and there's now a function in speex_bits that does

Looks good. Two things though: - I think the draft should be names -02 since the last one was -01 (I'm pretty sure). - The header in the current document should be changed (they say -01) Jean-Marc Le lun 01/03/2004 à 20:17, Greg Herlein a écrit : > > > > Is this the latest draft? > > > >

Here my comments: Page 3: To be compliant with this specification, implementations MUST support 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. The sampling rate MUST be 8, 16 or 32 kHz. There is a type above after (narrowband), there is a " extra character. I don't understand what is the motivation to specify "SHOULD support 8 kbps

On Thu, 17 May 2007, Jean-Marc Valin wrote: >>> Consider a device that only has enough ROM to store one set of >>> quantization tables (the limitation could also be about speed, network, >>> ...). If you specify MUST be able to decode, then it means that this >>> device simply *cannot* implement the spec *at all*. This is bad for >>> interoperability.

comment inline. On Wed, 16 May 2007, Jean-Marc Valin wrote: >> Page 3: >> >> To be compliant with this specification, implementations MUST support >> 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. >> The sampling rate MUST be 8, 16 or 32 kHz. >> >> There is a type above after (narrowband), there is a " extra

Hi Jean-Marc and list, I'm trying to negotiate speex with SIP/SDP and get some trouble understanding the "mode" parameter: mode: Speex encoding mode. Can be {1,2,3,4,5,6,any} defaults to 3 in narrowband, 6 in wide and ultra-wide. Is mode equivalent to the "quality" parameter of speex? In this case, I don't understand why mode is not from 1 to 10... Just

Jean-Marc and others, I'm meeting informally with the AVT WG on monday, and formally presenting our latest drafts on friday. I've been following the vorbis/theora draft efforts, but haven't paid much attention to the speex work. Can you brief me on what I should talk about, what we'd like feedback on, what's new and different from other drafts as far as the speex work goes?

Ivo Emanuel Gon?alves wrote: > Do not forget to add the "Copying conditions" to the RFC. > > Check http://wiki.debian.org/NonFreeIETFDocuments > I would be happy to add this statement. Could you let me know where to insert this statement in the xml document? I am using xml2rfc to generate the draft. Or alternatively point to other documents (.xml sources) that have the

On 6/1/07, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> wrote: > No, keep as is. It is definitely not public domain, since it's > BSD-licensed and "patent-free" will open futile and unnecessary > discussions (on what it's supposed to mean) at the IETF. I was under the impression that Speex, like Vorbis and FLAC had its specification under the PD, and only the

> I was under the impression that Speex, like Vorbis and FLAC had its > specification under the PD, AFAIK, under US law, the only way for something to fall in the public domain is for either 1) the author to be an employee of the US government or 2) the author to be dead for more than X years (X being larger than the age of Mickey Mouse). To the best of my knowledge (did I miss

FYI, -------------- next part -------------- An embedded message was scrubbed... From: Colin Perkins <csp at csperkins.org> Subject: Working group last call: draft-ietf-avt-rtp-speex-05.txt Date: Mon, 31 Mar 2008 22:25:03 +0100 Size: 2054 Url: http://lists.xiph.org/pipermail/speex-dev/attachments/20080331/289739db/attachment.eml

Jean-Marc Valin wrote: >> Also, we need to know why there is a "license" chapter (chapter 9) >> and we need to remove it because ietf don't like it... > > IIRC, the reason for the license is to make the document compatible with > the Debian licensing guidelines or something like that. > I would like to know if we should keep this additional license chapter

On 3/30/09, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote: > It seems to be related to debian, that doesn't like the fact that not > everyone is allowed to modify these documents. If it's that much > problem, I'd say just remove it. Guys, both the Vorbis RTP and the Ogg media types RFCs have this clause. It did not raise any problem. If there are problems

On Wed, 16 May 2007, Jean-Marc Valin wrote: >>> The main idea is that Speex supports many bit-rates, but for one reason >>> or another, some modes may be left out in implementations (e.g. for RAM >>> or network reasons). What we're saying here is that you should make an >>> effoft to at least support (and offer) the 8 kbps mode to maximise >>>

On 5/31/07, Alfred E. Heggestad <aeh@db.org> wrote: > Could you let me know where to insert this statement in the xml > document? I'm no expert, but I recommend adding it in the Full Copyright Statement section. More or less like this: Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as