Hi So far when I have streamed Vorbis, the headers (the 3 first frames/packets) was not included in the stream, but communicated out of band typically in an SDP file as unparsed A-lines. Rethinking that concept, I'm wondering if it is really necessary to do it that way. Isn't it possible in a platform independent way to regenerate useable headers on the client side using just the following parameters Vorbis version number of channels sample rate max bit rate nominel bit rate minimum bit rate So instead of using several thousand bytes, adding somthing to the SDP file like a=vorbis_header: "0,2,44100,128000,128000,-1" would be sufficient to regenerate the headers ignoring the loss of comments from the comment header. If comments were really needed, they could also be communicated out of band in the SDP file something like a=vorbis_comment: "Copyright" "Some One" a=vorbis_comment: "Date" "Some date" or a=vorbis_comment_url: "http://some_server/some_path/some_file" but that's rather dangerous for multicast if the client auto download the URL. So, back to my question - is there any reason why you shouldn't be able to completely regenerate the header packets/frames from what I have outlined ? --PMM ----------------------------------------------------------- Peter Maersk-Moller ----------------------------------------------------------- Ogg/Vorbis support for MPEG4IP and YUV12, XviD, AVI and MP4 for libmpeg2. See http://www.maersk-moller.net/projects/ ----------------------------------------------------------- --- >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-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.
>So, back to my question - is there any reason why you shouldn't >be able to completely regenerate the header packets/frames >from what I have outlined ?Unfortunately, yes. This requires that the _client_ have the encoder as well. Worse, it requires that the client have _exactly_ the same version of the encoder as the server. Michael <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-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.
Hi Michael Thx for the answer. > >So, back to my question - is there any reason why you shouldn't > >be able to completely regenerate the header packets/frames > >from what I have outlined ? > Unfortunately, yes. Why *unfortunately* ? > This requires that the _client_ have the encoder > as well. Worse, it requires that the client have _exactly_ the same > version of the encoder as the server. Please define "have _exactly_ the same version". Would Vorbis 1.0 and Vorbis 1.0rc3 have been two different versions in this context ? Both Vorbis 1.0 and Vorbis 1.0rc3 identify them selves as Vorbis version 0. If Vorbis 1.0 and Vorbis 1.0rc3 would have been different versions in the context we are talking about, then how does a program identify which version the library is ? Kind regards ----------------------------------------------------------- Peter Maersk-Moller ----------------------------------------------------------- Ogg/Vorbis support for MPEG4IP and YUV12, XviD, AVI and MP4 for libmpeg2. See http://www.maersk-moller.net/projects/ ----------------------------------------------------------- --- >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-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.
Hi Segher Boessenkool wrote:> Michael Smith wrote: > > >So, back to my question - is there any reason why you shouldn't > > >be able to completely regenerate the header packets/frames > > >from what I have outlined ? > > Unfortunately, yes. This requires that the _client_ have the encoder > > as well. Worse, it requires that the client have _exactly_ the same > > version of the encoder as the server. > Worse still, some encoders generate their headers partly based on the > actual audio encoded, not based only on the encoder settings.Which encoders. The ones from Xiph I have been using generate the headers before audio data is available - and thanks for that.> Which is a good thing really (better compression).That was what I thought Vorbis did until I started using it. Then I also realised that 5 secs, or 5000 secs if you like, almost never will or can be representative for anything. Just turn on the radio and listen for 5 secs and then try to see if it will be representative for what you will hear 60 secs or 600 secs later. Kind regards ------------------------------------------------------------------------------ Peter Maersk-Moller ------------------------------------------------------------------------------ Ogg/Vorbis support for MPEG4IP and YUV12, XviD, AVI and MP4 for libmpeg2. See http://www.maersk-moller.net/projects/ ------------------------------------------------------------------------------ --- >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-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.
Hi Michael> At 12:17 AM 22/11/2002 +0100, you wrote: > >Hi Michael > >Thx for the answer. > > > >So, back to my question - is there any reason why you shouldn't > > > >be able to completely regenerate the header packets/frames > > > >from what I have outlined ? > > > Unfortunately, yes. > >Why *unfortunately* ? > Because it'd be really useful to be able to do as you suggested, > so not being able to is unfortunate.Yes, of course - I just failed to read what I had actually written. Stupid me. Now I'm not suggesting you to drop the headers, just trying to see where and when corners can be cut. That said, the headers are for sure a pain trying to combine ultra large scale multicast with chained Ogg/Vorbis. Wrt. players being without encoders, that might be true. On the other hand, the code to generate the headers does not take up much space, but that is not the only option. If the encoder and the decoder can ask the vorbis library for a major and minor version number, then if the version number of the encoder is passed out of band to the decoder, then the decoder can look in a sort of header cache for the appropriate header and only download (or generate new) headers if they are not present in the cache. So access from the application to a detailed version number in the vorbis library would be appreciated. --PMM ------------------------------------------------------------------------------ Peter Maersk-Moller ------------------------------------------------------------------------------ Ogg/Vorbis support for MPEG4IP and YUV12, XviD, AVI and MP4 for libmpeg2. See http://www.maersk-moller.net/projects/ ------------------------------------------------------------------------------ --- >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-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.