Hi all,
The remaining issue to be decided for the OggPCM2 spec is the support
of chunked vs interleaved data.
Just so that everyone understands what we are talking about, consider a
stereo file that gets stored as an OggPCM file. Within an OggPCM packet,
the audio samples for the left and right channels can be stored as
interleaved where the samples would be:
l0, r0, l1, r1, ..... lN, rN
or as chunked where the samples would be:
l0, l1, l2, ..... lN, r0, r1, r2, .... rN
So the question is do we support:
a) interleaved
b) chunked
c) both
This is file level storage. An API for reading this data could still
allow the demulitplexing/re-multiplexing on the fly.
Opinions?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Open source is an intellectual-property destroyer. I can't
imagine something that could be worse than this for the software
business and the intellectual-property business."
-- Jim Allchin, Microsoft
Le mardi 15 novembre 2005 ? 19:58 +1100, Erik de Castro Lopo a ?crit :> The remaining issue to be decided for the OggPCM2 spec is the support > of chunked vs interleaved data.My take on this is that we definitely need to support interleaved format as this is the format used by WAVE, most soundcard APIs and just about everything. I'm not as sure about the other one, but I think we should not support chunked format because: 1) It makes the implementation more complicated 2) Few applications use it so it not too hard to convert for these 3) Even if we support chunked, apps that want chunk data would still need to have code to support interleaved. That being said, I might change my mind on chunked support if you think I overlooked something. Jean-Marc> Just so that everyone understands what we are talking about, consider a > stereo file that gets stored as an OggPCM file. Within an OggPCM packet, > the audio samples for the left and right channels can be stored as > interleaved where the samples would be: > > l0, r0, l1, r1, ..... lN, rN > > or as chunked where the samples would be: > > l0, l1, l2, ..... lN, r0, r1, r2, .... rN > > > So the question is do we support: > > a) interleaved > b) chunked > c) both > > This is file level storage. An API for reading this data could still > allow the demulitplexing/re-multiplexing on the fly. > > Opinions? > > Erik
On 11/15/05, Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote:> Hi all, > > The remaining issue to be decided for the OggPCM2 spec is the support > of chunked vs interleaved data.I think interleaved is the obvious choice - that's what most audio applications are used to dealing with, it's what we need to feed to audio hardware in the end usually, etc. Whilst I accept that there are many good uses for chunked data, I think the transformation is trivial, particularly given certain characteristics of the Ogg container. Remember, the data, if you read an ogg stream into memory, is _already_ likely to be non-contiguous, due to ogg's structure. It's trivial, and has insignificant additional overhead, to de-interleave as you read it into a packet buffer. So, you've forced additional implementation complexity onto all implementations, but the benefits aren't obviously significant. Oh, and if it's not already obvious, I support this spec, rather than Arc's. Mike
I made a few updates to OggPCM2 http://wiki.xiph.org/index.php/OggPCM2 reflecting the latest discussions. Could everyone have a look at it and see if they agree. Otherwise, what do you feel should be changed? Anyone wants to speak in support of chunked PCM? For all those that are just tired of this mess like me, please express yourself in the new spec I created: OggPCM3 http://wiki.xiph.org/index.php/OggPCM3 Jean-Marc P.S. So far, I think we have OggPCM2 5, OggPCM 0. Please vote for OggPCM3! :-) Le mardi 15 novembre 2005 ? 11:21 +0100, Michael Smith a ?crit :> On 11/15/05, Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote: > > Hi all, > > > > The remaining issue to be decided for the OggPCM2 spec is the support > > of chunked vs interleaved data. > > I think interleaved is the obvious choice - that's what most audio > applications are used to dealing with, it's what we need to feed to > audio hardware in the end usually, etc. > > Whilst I accept that there are many good uses for chunked data, I > think the transformation is trivial, particularly given certain > characteristics of the Ogg container. Remember, the data, if you read > an ogg stream into memory, is _already_ likely to be non-contiguous, > due to ogg's structure. It's trivial, and has insignificant additional > overhead, to de-interleave as you read it into a packet buffer. > > So, you've forced additional implementation complexity onto all > implementations, but the benefits aren't obviously significant. > > Oh, and if it's not already obvious, I support this spec, rather than Arc's. > > Mike > _______________________________________________ > ogg-dev mailing list > ogg-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev >
Michael Smith wrote:>Whilst I accept that there are many good uses for chunked data, I >think the transformation is trivial, particularly given certain >characteristics of the Ogg container. Remember, the data, if you read >an ogg stream into memory, is _already_ likely to be non-contiguous, >due to ogg's structure. It's trivial, and has insignificant additional >overhead, to de-interleave as you read it into a packet buffer. > > >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). 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. To clarify, I'm okay with sticking to interleaved, this just seemed like low hanging fruit that could be useful to somebody, the gstreamer and JACK folks in particular. John