Hi! What happened to this document? Was it just left dying in the IETF system? Tor --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Tue, May 25, 2004 at 03:24:05AM +0200, Tor-Einar Jarnbjo wrote:> Hi! > > What happened to this document? Was it just left dying in the IETF system? >Hi, The current state of the draft, and a log of subsequent discussions, is in the vorbis docs at: http://www.xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html#vorbis-over-rtp It was mentioned at the last IETF avt wg meeting as still requiring some issues to be resolved before it can proceed. IIRC Phil is not able to continue working on it, so it needs someone like you to work over it :) The IETF is a collaborative system, very much like open source. Don't expect stuff to be done for you, just pitch in and help out. Conrad. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Tirsdag, 25 mai 2004, skrev du:>the full text of that draft, and some copies of discussions on >vorbis-dev and the avt listIf just somebody could point me out _where_ this is kept. I have been searching for it and haven't found anything. The Vorbis documentation only includes version 00 of the draft: http://www.xiph.org/ogg/vorbis/doc/draft-moffitt-vorbis-rtp-00.txt I would at least need the latest version of the draft and access to IETF's objections against it if I should be able to do some work on it. Tor <p><p><p>==================================================================EASY and FREE access to your email anywhere: http://Mailreader.com/ ================================================================== <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Tirsdag, 25 mai 2004, skrev du:>I think the latest version was draft-kerr-avt-vorbis-rtp-03.txt: > > http://www.watersprings.org/pub/id/draft-kerr-avt-vorbis-rtp-03.txtI am pretty sure that there was a version 04 of the draft released around October last year. That would also match a recent expiration of the document. Version 03 is from April last year and would have expired around October last year.>The discussions happened on vorbis-dev and the avt list: > > http://www1.ietf.org/mail-archive/web/avt/A good illustration of my problem. There's no search functionality in the mailing list archive and a traffic of 20-30 mails/week makes 2-3000 potentially relevant messages within the last two years. Are they really expecting people to find any information in there? The only discussion about the RFC draft on the vorbis and vorbis- dev mailing lists was in the beginning of 2003, where I made a few suggestions to changes in version 00. I do not find any relevant comments on the later versions on those mailing lists (searching for "rtp vorbis"). Tor <p><p><p><p>==================================================================EASY and FREE access to your email anywhere: http://Mailreader.com/ ================================================================== <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> I think delivery in the RTP channel should be possible, but I don't > understand how you intend to handle dropped header packets. RTP > generally used unreliable transport, and the stream is of course > not decodable without the info and setup headers.There are a number of FEC codes available for free which should make the transmission of headers via RTP more robust. (see http://info.iet.unipi.it/~luigi/fec.html ) The headers should still be available on demand via a unicast mechnism for 'late joiners' and those who still missed the FEC protected headers. It would also be nice if clients had a way to cache headers so if they late-joined later they'd likely have them. If such mechnisms were in place the transmitter could decide to transmit the headers inline or not.. A smart method might be to only transmit them if they differ from the last file (or more agressively within some other time window.. or perhaps never send them). If it is decided that 'less than always' is acceptable, then there should be some mechnism for the server to transmit "you're going to need header sig X if you don't have it, here it is..." or "You're going to need header sig Y if you don't have it better go get it" so clients have a chance to get it via unicast in advance if it won't be in the RTP or get corrections if part of the transmission was lost. Obviously if a client has failed to obtain the headers for a new content there will be some gap in playback when the headers change. It wont always be possible to know well in advance that the headers will change, so RTP transmission of the headers is important. A possible method of transmitting headers via unicast would be with via http with URL transmitted in SDP. The advantage of using HTTP would be that existing scalablity mechnisms (such as squid cache hierarchys or reverse proxys like Akamai) for HTTP could be used. It would be advantagious if the HTTP server contained the FECed representation of the codebooks, this way clients could obtain only the lost poritions via http byte-range requests. (If only the raw headers were stored clients would need to obtain the whole thing as the FEC likely won't provide partial decode for something as small as the headers are). <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Onsdag, 26 mai 2004, skrev du:>All the files produced by current encoders >use the same set of codebooks for the same configurations anyways.Yes, but this is only valid for the current encoders. A future encoder may choose to create the codebooks while encoding, making an optimized set for the current input. Like sort of integrating Segher's tool (which name I've forgotten) with a current encoder. A chain with two such files would then not be streamable.>I'm not saying "pick a set of codebooks" for everything. I'm saying >send a single set of codebooks on setup, and restrict the stream to >_that_ set for the duration. Essentially disallowing chains over RTP.Yes, but I'm not sure if I like that limitation. Broadcasters are currently using chains to allow a midstream change in the metadata (comment header, title, artist) and this is a feature which should be preserved when using RTP too. One option would of course be to allow comment headers to appear between audio packets.>We don't change codebooks "on the fly". New encoders use new codebooks.>All current encoders that I know of have used a fixed set of codebooks >for that encoder generation. But there are several generationsof these>fixed sets.Yes, this is the current state, but as I wrote earlier, it could be reasonable for future encoders to either have more fixed codebook settings for the same quality setting, selecting different codebook sets, depending on the encoded audio, or even generate new codebooks while encoding.>Exactly. I think in the case of streaming, it is more or less expected >that a stream will have a fixed set of parameters. I can't thinkof any>counter arguments off the top of my head, so this idea seems like a >valid and worthy compromise.So what do you think about restricting the identification header and the setup header to remain static for the entire broadcast, but allow the comment header to be repeated? Or perhaps use some other content type to deliver meta data? Tor <p><p><p><p>==================================================================EASY and FREE access to your email anywhere: http://Mailreader.com/ ================================================================== <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Onsdag, 26 mai 2004, skrev du:>Thus my statement that you could use existing scalability mechnisms.. If>you don't have access to something like that and there will be thousands >of clients you're free not to provide http access to the headers. The >disadvantage is that clients will get no audio unless they have the >headers cached until you retransmit them.At least this is just an issue for multicast servers. If you don't have the resources to deliver thousands of codebooks at the same time, you for sure don't have the resources to handle the accumulating number of unicast RTP streams. Would it make sense to also define a multicast way of broadcasting the codebooks instead of HTTP? Tor <p><p><p>==================================================================EASY and FREE access to your email anywhere: http://Mailreader.com/ ================================================================== <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.