[vorbis-dev] Ogg as container format

[Michael Smith]

>>Pages are a way of freezing packets of arbitrary size into a stream.
>>
>>You've obviously read the spec, you just need to think a little more
>>about it.
>
>Are the packets related to the encoding or not? For Vorbis, they seem 
>to be, with a single packet corresponding to a frame of audio.

Yes, they are (in some way) related to the encoding. In the particular
case of vorbis, a packet IS (saying it corresponds to this is misleading,
since this is the actual data, by itself, with NO other information) a
block (or 'frame', though that's not a word used in vorbis).

>>One would never put an entire frame in one packet.  One *could*, but
>>that would be silly.  Think about why.  Others may feel free to chime in.
>
>Here you seem to imply that the packets are to do with RTP networking 
>units. For DV do you use the DV RFC to decide these? Or are they 
>arbitrary? You have 2 size-limited structures overlaid on each other, 
>neither of which necessarily corresponds to a fundamental data unit 
>of the underlying media.

Well, vorbis packets are size limited, so technically this is true. 
However, given that the limited size in this case is 2^32-1 bytes, or
around 4 GB, it's essentially unlimited for practical purposes. This
restriction would be pretty easy to remove if it proved neccesary, too.

We have one layer for framing and synchronisation, which has sizes not
particularly related to the data in the stream itself. THEN, we have 
a layer containing the raw data, in a form suited to the codec in use.
Generally, the packets do correspond to _some_ fundamental data unit,
though it will often not be the most obvious unit (in video, a frame is
a pretty obvious choice, but not terribly suitable. The actual choice
would be dependent on the specific codec in use).

>
><sarcasm>
>You call QT old-fashioned, and then include hard-limited 64k page 
>sizes? I'm having DOS flashbacks here. Looks like you have a great 
>format for video, as long as it's 320x200 8-bit  VGA Mode 13h.
></sarcasm>

The page size is hard limited for good reasons, and this is NOT a 
restriction. Packets can (and in vorbis, frequently DO) span pages, this
is just being stupid and deliberately misleading.

>If you happen to chain 2 files that use the same stream serial 
>number, you are hosed, as you'll get packets that belong to the wrong 
>stream when doing this. to prevent this, a server will have to 
>rewrite each page header with a unique stream number as it goes out.

No, you aren't hosed. It is not possible to have a stream containing
two chained logical streams with the same serial number. This is what
the term 'serial number' means. It is (locally, not globally) unique.
I'm sure it's possible to create an invalid quicktime that can't
be decoded properly, too. 

For other reasons (among which is fixing up existing files which are
slightly broken in one way or another) rewriting the pages as they go
out in a server is a useful thing to do anyway (I'm about 2/3 of the 
way through adding such code to ices2).

>RTP streaming then. HTTP does not need packet boundaries in the file. 
>It is a stream in the filestream sense instead.

For actual streaming purposes, no, HTTP does not need packet boundaries.
However, the codec decoding the file as it comes in still needs packet
boundaries in every interesting case, unless you have self-delimiting 
data (which is relatively uncommon. vorbis packets don't know their own
lengths, certainly, which is why a framing layer (whether it be RTP or
ogg) is needed).

Michael

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.