similar to: Speex and Jabber

>>>>> "Greg" == Greg Herlein <gherlein@herlein.com> writes: Greg> The IETF has already assigned -02: ... to indicate it's Greg> expired. I'll ask if they want to use -02 or -03. They posted a policy statement a couple of weeks back. The expired notice is to be replaced by the next version of the draft if any is forthcoming. So it'll be -02.

Do not forget to add the "Copying conditions" to the RFC. Check http://wiki.debian.org/NonFreeIETFDocuments That page contains a section titled "Template for RFC authors to release additional rights". To follow that guideline a section like the following should be added: x. Copying conditions The author(s) agree to grant third parties the irrevocable right to

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

Hi all We are about to send an updated version of the internet draft "RTP Payload Format for the Speex Codec" to the IETF AVT working group. Before submitting we would like your input, if you have any comments or input please send them to the mailing list. If we don't get any comments in 1 week (by 22. May 2007) we will go ahead and submit it to the IETF. Of course you can comment

Looks good to me. Jean-Marc Alfred E. Heggestad a ?crit : > Hi > > Please find an updated version of the Speex I-D attached. The only > change is addition of the copyright conditions in Appendix A, > as requested by Ivo. > > Many thanks for your input. > > I will give you a few more days before submitting to AVT working group > > > /alfred > > Ivo

On Wed, Jan 14, 2004 at 07:35:48PM -0500, Jean-Marc Valin wrote: > > Does the stable release support the new draft? > > Yes. Version 1.0.1 makes it easier (than 1.0.0) to implement the draft, > but even with 1.0.0 it's not that hard. The only thing that changed is > the "terminator" that allows a variable number of frames per packets > (instead of a negotiated

Hi all, This year, as last year, Xiph's planning on applying to be part of Google's Summer of Code program. We're going to send in our application tomorrow, so: If you're interested in mentoring a project as part of Xiph, see (and add to) our list of proposed projects. We can't, of course, guarantee anything at this point, but any willing mentors are welcome:

Hi all, This year, as last year, Xiph's planning on applying to be part of Google's Summer of Code program. We're going to send in our application tomorrow, so: If you're interested in mentoring a project as part of Xiph, see (and add to) our list of proposed projects. We can't, of course, guarantee anything at this point, but any willing mentors are welcome:

Hi all, This year, as last year, Xiph's planning on applying to be part of Google's Summer of Code program. We're going to send in our application tomorrow, so: If you're interested in mentoring a project as part of Xiph, see (and add to) our list of proposed projects. We can't, of course, guarantee anything at this point, but any willing mentors are welcome:

Hi all, This year, as last year, Xiph's planning on applying to be part of Google's Summer of Code program. We're going to send in our application tomorrow, so: If you're interested in mentoring a project as part of Xiph, see (and add to) our list of proposed projects. We can't, of course, guarantee anything at this point, but any willing mentors are welcome:

Hi all, This year, as last year, Xiph's planning on applying to be part of Google's Summer of Code program. We're going to send in our application tomorrow, so: If you're interested in mentoring a project as part of Xiph, see (and add to) our list of proposed projects. We can't, of course, guarantee anything at this point, but any willing mentors are welcome:

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

Hep On Fri, May 16, 2003 at 12:04:43AM +1000, Michael Smith wrote: > For entirely different reasons, an RTSP implementation in icecast would be a > Very Good Thing, but it's an extremely large task. I don't think anyone has > tried yet. Maybe another and easier way would be to implement the ogg vorbis format in Real Networks "open sourced" Helix streaming server

On Tue, Dec 17, 2002 at 11:55:21PM -0800, Greg Herlein wrote: > If such a thing happens, discussion of the RTP profile draft > would be most welcome - please get responses back to the > list! Now, if this were finalised before the conference then we could do a demo and use it for broadcasting the lectures streams around the world... What is currently the best way of doing this? I'm

Hi, does anybody know if somebody tried implementing things like rtsp, mms or similar in icecast so far? I heard some rumors from people complaining transmissions over http or not "that secure" because using a wget you can easily write them to disk. They suggested using real servers or something - but I wonder if its (easy?) possible to implement another already widely used

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? > > > >

> The cost of down-sampling, if done efficiently, is probably less then > the cost difference between 32 kHz and 44.1 kHz so it's probably worth > it. If you don't care about standard sampling rate, you could even to a > 2/3 conversion which would get you 29.4 kHz... I'm curious why not just sample at a lower rate if it's just VoIP anyway? My opinion is that 44kHz

Well more specifically I want to transcode a realaudio stream into mp3 on the same machine and on the command line only - reliably! Following up, I managed to compile the trplayer using a substitute __pure_virtual function compiled with extern "C" (without it the function name was being mangled by g++) by now trplayer runs and exits without warning, error or success... the funny thing

Jean-Marc Valin wrote: > AFAIK the padding changed with the latest draft and there's now a > function in speex_bits that does it all for you (and it's also called by > speex_bits_write). What that does is that it inserts a special > terminator, which allows a variable number of frames per packet without > any overhead. Does the stable release support the new draft? Is

samurai.fm wrote: > Well more specifically I want to transcode a realaudio stream into mp3 on > the same machine and on the command line only - reliably! > > Following up, I managed to compile the trplayer using a substitute > __pure_virtual function compiled with extern "C" (without it the function > name was being mangled by g++) by now trplayer runs and exits