[ogg-dev] OggPCM2 : chunked vs interleaved data

[Michael Smith]

On 11/15/05, John Koleszar <jkoleszar at on2.com> wrote:
> Could you elaborate on this? I'm not familiar enough with the ogg API,
> but as far as I can tell, the way you'd do this would be to get the
> whole interleaved packet out with ogg_stream_packetout and then walk
> through it to de-interleave it into another buffer (or in place, I suppose).

I was mostly talking about the Ogg file format, as I think that's the
right approach to take when discussing format design. Yes, with the
libogg API, that's how it'd work - but that's "merely a matter of
implementation". An implementation could also do the de-interleaving
at the same time as it did the equivalent of ogg_stream_packetout().
libogg2, for instance, does not give packets to applications in a
contiguous buffer.

>
> My feeling is that if you're working with files, the time it takes to
> interleave/deinterleave is probably negligible with respect to the i/o
> time, but if you're working with pipes or some other low latency
> transport, it's more significant. I proposed it because it didn't seem
> like it was a big deal to store it either way and frequently use both in
> the video world, but I defer to others as to whether it makes sense
> here. Out of curiosity, do more people object because there isn't a
> clean way to specify that the data is non-interleaved, or is it just
> that the data's harder to use because you could potentially have to
> interleave it? The latter issue seems to me like it should be taken care
> of by a good library API to me and that it shouldn't matter to most
> applications.

I would certainly agree that if you're working with anything where
you're interested in low-latency, this could potentially be
significant. However, I'd argue that in such a case, you're probably
not interested in using Ogg to begin with (apart from anything else,
the requirement to checksum the pages - with the checksum existing in
page headers, but covering the entire page body) already sets a limit
to what you can manage latency-wise.

Mike