[ogg-dev] Fwd: Fwd: New Ogg Dirac mapping draft

[Ralph Giles]

On Wed, Aug 13, 2008 at 3:05 AM, ogg.k.ogg.k at googlemail.com wrote:

> And that's the canonical way AFAIK. Comparing times computed from
> the granpos you get from pages you get from a bsearch requires good
> knowledge of the codec, whereas comparing granpos can seek within
> any codec.

No. it's in general impossible to calculate the granulepos that
corresponds to a particular time in a theora stream; only the reverse
is possible. That's why David was talking about comparing High Word +
Low Word, which is the frame count in theora, and can be treated as
the seek time in different units.

>> OTOH, the RFC can be read to require the numeric values be increasing.
>
> I recall pointing out a discrepancy between Ogg docs and the RFC, and
> I think someone (either Silvia or Conrad, probably Silvia) fixed the RFC.
> (That was the reason I'd originally included the low counter bits for Kate).

Right, thanks for pointing that out. The correction is recorded at
http://wiki.xiph.org/RFC_3533_Errata

David's proposal still violates that without the "stop the press"
fancier encoding.

> I'll take this opportunity to mention my pet idea (don't think I ever mentioned
> it on ogg-dev), to start with a byte, then, if larger than 255, add two bytes,
> then for packets larger than 255+65536, add 4 bytes. This lacing is worse
> than the current one only for packets between 256 and 511 bytes (admittedly
> a probably common case, but adding only one byte). Now that you mention
> flags, lacing type could be put in flags, so this worsening could be avoided
> too.

So this would be:

len = read_uint8()
if (len == 255):
 len += read_uint16()
 if (len == 255+65535):
   len += read_uint32()

And a len of 2^32 - 1 would indicate a continued packet?

We can't change the lacing scheme without changing the stream
structure version. So I'd propose something like:

stream_structure_version = 1
header_type_flags:
 bit 0 : fresh/continued packet
 bit 1 : bos
 bit 2 : eos
new flags:
 bit 3 : CRC is only the header data
 bit 4-5: 0 is traditional lacing, 1 is 16 bit packet length, 2 is 32
bit packet length, 3 is 64 bit packet length.
 The packet length field would start on byte 26 where the segment
table length is in the traditional lacing. Using this kind of length
encoding implies one packet per page with no continuation.

If the lacing type and crc flags are zero, stream structure can be
zero. Muxers SHOULD not mix stream structure values within a logical
bitstream to avoid confusing legacy implementations.

 -r