> speex and flac have an "extra headers" field in the bos page, and > skeleton also has a field for recording the total number of headers > (as it's kinda important for editing files). If you know how many > headers there are going to be at the start of encoding, then adding a > field like that might be enough.I do know at start, and I have such a field too. However, I was concerned about the RTP streaming case, where packets may be lost, and the "other" container case, where they have to be concatenated (and thus one needs a way to walk past them easily). I reckon I'll just add a "header length" to headers past the first one, and maybe on data packets as well. I'm not clear at all on what would happen when not in Ogg, I need to think more about this case. Cheers
On 13-Feb-08, at 3:40 AM, ogg.k.ogg.k@googlemail.com wrote:> However, I was concerned about the RTP streaming case, where packets > may be lost, and the "other" container case, where they have to be > concatenated (and thus one needs a way to walk past them easily). > I reckon I'll just add a "header length" to headers past the first > one, and > maybe on data packets as well. I'm not clear at all on what would > happen > when not in Ogg, I need to think more about this case.There are a usually lot more data packets than header packets, so having an internal length there hurts your bitrate a lot more. Of course, it may not be significant for an uncompressed text codec. With codecs using the 'count of decodable samples' rule to calculate their granulepos, the headers can often be distinguished by having a granulepos that maps to time zero. I know that works with theora (after the change in beta1). Conrad, does this work for the other codecs as well? I vaguely remember libvorbis putting -1 on the header packets instead of 0. -r
> There are a usually lot more data packets than header packets, so > having an internal length there hurts your bitrate a lot more. Of > course, it may not be significant for an uncompressed text codec.If muxed with a video, it's insignificant (well, for my test cases).> With codecs using the 'count of decodable samples' rule to calculate > their granulepos, the headers can often be distinguished by having a > granulepos that maps to time zero. I know that works with theora > (after the change in beta1).But this for when they're encapsulated in ogg, isn't it ? All is fine when that is the case, since Ogg provides the framing already so there's no need to walk the packets.> Conrad, does this work for the other codecs as well? I vaguely > remember libvorbis putting -1 on the header packets instead of 0.AFAIK, it's 0, -1 being for partial pages, from the ogg docs. -1 (or, I suppose all negative values, but I'm not sure) mean unset. Though you do say packets rather than pages, and the granulepos for a vorbis packet will be interpolated from the page's granulepos, so I assume you meant page ?
On 14/02/2008, Ralph Giles <giles@xiph.org> wrote:> On 13-Feb-08, at 3:40 AM, ogg.k.ogg.k@googlemail.com wrote: > > > However, I was concerned about the RTP streaming case, where packets > > may be lost, and the "other" container case, where they have to be > > concatenated (and thus one needs a way to walk past them easily). > > I reckon I'll just add a "header length" to headers past the first > > one, and > > maybe on data packets as well. I'm not clear at all on what would > > happen > > when not in Ogg, I need to think more about this case. > > There are a usually lot more data packets than header packets, so > having an internal length there hurts your bitrate a lot more. Of > course, it may not be significant for an uncompressed text codec.there's also the possibility of having a marker in the first byte to say whether its a header packet or not, kinda like how vorbis and theora start their header packets with (0x1, 0x3, 0x5,) and (0x80, 0x81, 0x82) respectively ... and then make sure not to start data packets that way. That does make it a little dirty for a text codec though as you always have to check/skip the first byte of your data packets. Conrad.