> It's nice if the first header is small, because it lets you find the > beginning-of-stream (bos) packets for all the streams quickly, > ideally within a single read buffer, so you can configure the decoder > pipeline. Currently the bos headers we have for codecs in Ogg are all > less than 100 bytes.Same for me, all good here.> Otherwise, I don't suppose it matters much. The other main > recommendation is that all the headers go together at the beginning, > with a page flush after the last one, so it's easy to (a) find them > and (b) copy and paste them when you're doing editing.OK, I was thinking of whether there would be a "generic" way of skipping packets which would be used for various codecs (eg, the header packet walking described for theora and vorbis, which would be quite a bit more complicated for kate due to the extra headers).> * Ogg requires some way to identify the codec from the first packet.[...]> * Likewise, and regardless of whether you're using Ogg, it's nice if > other parameters that might be relevant to setting up a pipeline are > easy to extract without a full parser: frame size for video codecs, > number of channels for audio codecs, that sort of thing.OK, so it looks like it's all fine, then. Thanks for the info.
On 13/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote:> OK, I was thinking of whether there would be a "generic" way of skipping > packets which would be used for various codecs (eg, the header packet > walking described for theora and vorbis, which would be quite a bit more > complicated for kate due to the extra headers).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. Conrad.
> 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