[ogg-dev] OggPCM version / header finalization

[Silvia.Pfeiffer at csiro.au]

Hi John, all,

I still have at least 3 issues:

1) What are we trying to achieve with the "source-ID"?
 8  [uint]     Source ID (Unique amongst all OggPCM streams in the physical stream)

Are we trying to separate the different channels that may be interleaved with each other inside the flat multi-channel sample stream?

Interpretation 1:
-----------------
So, would each channel be in a separate OggPCM logical bitstream and interleaving would happen at the ogg level? If that is the case, then this is unnecessary since every logical bistream in Ogg framing already gets attributed a different serial number in the page header.

To illustrate:
(and just for the record: I don't think this is the way to go).

          logical bitstream with samples for 6 channels
 ----------------------------------------------------------------
 > |1|2|3|4|5|6|1|2|3|4|5|6|1|2|3|4|5|6|1|2|3|4|5|6|1|2|3|4|5|6|<
 ----------------------------------------------------------------

                     | reordering into 6 logical bitstreams
                     v

          logical bitstreams for 6 channels
 --------------- --------------- --------------- ---------------
 > |1|1|1|1|1| < > |2|2|2|2|2| < > |3|3|3|3|3| < > |4|4|4|4|4| < etc.
 --------------- --------------- --------------- ---------------

                     | segmentation for each logical bitstream
                     v

      packet_1 (1)                   packet_2 (1)
     ------------------------------ -------------------
 ..  |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3| ..
     ------------------------------ -------------------


      packet_1 (2)                   packet_2 (2)
     ------------------------------ -------------------
 ..  |seg_1|seg_2|seg_3|seg_4|s_5 | |seg_1|seg_2|seg_3| ..
     ------------------------------ -------------------

etc.
                     | page encapsulation
                     v

 page_1 (pkt_1(1) data)   page_2 (pkt_1 data)   page_3 (pkt_2 data)
------------------------  ----------------  ------------------------
|H|------------------- |  |H|----------- |  |H|------------------- |
|D||seg_1|seg_2|seg_3| |  |D|seg_4|s_5 | |  |D||seg_1|seg_2|seg_3| | ...
|R|------------------- |  |R|----------- |  |R|------------------- |
------------------------  ----------------  ------------------------

 page_1 (pkt_1(2) data)   page_2 (pkt_1 data)   page_3 (pkt_2 data)
------------------------  ----------------  ------------------------
|H|------------------- |  |H|----------- |  |H|------------------- |
|D||seg_1|seg_2|seg_3| |  |D|seg_4|s_5 | |  |D||seg_1|seg_2|seg_3| | ...
|R|------------------- |  |R|----------- |  |R|------------------- |
------------------------  ----------------  ------------------------

etc.

                      | multiplexing
                      v

physical bitstream
(1)                       (2)
------------------------  ------------------------
|H|------------------- |  |H|------------------- |
|D||seg_1|seg_2|seg_3| |  |D||seg_1|seg_2|seg_3| | ... etc.
|R|------------------- |  |R|------------------- |
------------------------  ------------------------


Interpretation 2:
-----------------
Or are we trying to describe how the data of the different channels are interleaved with each other inside the one one flat logical bitstream? Then I think this one field should *not* provide an ID but rather an interleaving description. Since usually channels are just consecutively ordered (if I'm not mistaken), this information may not be necessary at all.

To illustrate:

          logical bitstream with samples for 6 channels
 ----------------------------------------------------------------
 > |1|2|3|4|5|6|1|2|3|4|5|6|1|2|3|4|5|6|1|2|3|4|5|6|1|2|3|4|5|6|<
 ----------------------------------------------------------------

                     | packet definition
                     v

e.g. take 2 complete samples as a packet (just to illustrate!)
     packet_1                  packet_2
     ------------------------- ------------------------- 
 ... |1|2|3|4|5|6|1|2|3|4|5|6| |1|2|3|4|5|6|1|2|3|4|5|6| ...
     ------------------------- -------------------------

                     | segmentation
                     v

      packet_1                         packet_2
     -------------------------------- -------------------------------
 ..  |seg_1|seg_2|seg_3|seg_4|seg_5 | |seg_1|seg_2|seg_3|seg_4|seg_5| ..
     -------------------------------- -------------------------------

                     | page encapsulation
                     v

 page_1 (pkt_1 data)       page_2 (pkt_1 data)   page_3 (pkt_2 data)
------------------------  -----------------  ------------------------
|H|------------------- |  |H|------------ |  |H|------------------- |
|D||seg_1|seg_2|seg_3| |  |D|seg_4|seg_5| |  |D||seg_1|seg_2|seg_3| | ...
|R|------------------- |  |R|------------ |  |R|------------------- |
------------------------  -----------------  ------------------------


2) I don't understand what the "channel block" is for?
What is it trying to describe?

3) I also still don't understand why packets require an extra landmark (i.e. the data packet header).
I don't buy into Arc's argument that this framing is necessary to keep space for potential future additional header fiels. No other uncompressed audio format requires extra framing and header information for the samples (FAIK), so I cannot see how future additional header fields would require to be added. It should be made clear in the bos page how many samples go into a packet and thus packed framing is unnecessary. This field is just complicating decoding through an unnecessary extra parsing step IMHO.


Cheers,
Silvia.


-----Original Message-----
From:	ogg-dev-bounces at xiph.org on behalf of John Koleszar
Sent:	Fri 11/11/2005 6:43 AM
To:	ogg-dev at xiph.org
Cc:	
Subject:	[ogg-dev] OggPCM version / header finalization
I have OggPCM (as currently defined) support implemented in mencoder and 
mplayer. I'd like to request that we settle on modifications to this 
header by the middle of next week or freeze the current header as the 
official major version 1.0, so I can get the patches cleaned up and 
released. We will be shipping a separate product based on this work in 
the near-term future, and compatability with a community standard is a 
desired bullet.

Thanks..

John




_______________________________________________
ogg-dev mailing list
ogg-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/ogg-dev