[Theora-dev] Ogg spec

Michael Smith msmith at xiph.org
Thu Nov 11 15:59:34 PST 2004


On Friday 12 November 2004 10:53, Robert Brautigam wrote:
> Hi,
>
> I'm currently trying to implement the Ogg specification in pure Java
> from scratch. (I know, something like that does exist, but that's a rewrite
> from C, at least that's my impression).
> I'm a bit confused with the number of lacing values/segments in a page,
> and the maximum length a page can have. The specification says, that
> there can be 255 segments in a page, 255 bytes each + 27 bytes header =
> 65052. But later it states the maximum size of a page is 65307 which is
> strangely 255*256+27. Now where does that extra segment come from?
> I tried to read every FA I've found, and the mail archives, but couldn't
> figure this one out. Either I don't "get" something, or that's simply
> miscalculated.

There's no extra segment: your extra 255 bytes are the lacing table itself 
(which, in a maximally-sized page, obviously takes up 255 bytes to describe 
the 255 segments!)

> Similar minor issue: How does one describe a 'nil' page. The reference
> implementation libogg-1.1.1 seems to write a 'page_segment' of 0, and no
> lacing values, but the rfc states, that a 'nil' page contains only a
> lacing value of 0 (so a page_segment value of 1). Of course both seem
> correct, but which is it then?

Those _are_ different: if there's an incomplete packet on the previous page, a 
zero lacing value will signal the end of the packet, but a true nil page 
(with no lacing values) will not. 

I'm not sure what the intent is - Monty might know?

It looks to me like it might be a mistake in the RFC - but it'd only make a 
difference in the case I described before, and I can't really see why you'd 
actually want to use a empty page in that case. Obviously, in a decoder, you 
can handle both correctly fine - I assume you want to know what your encoder 
should do? I'd probably match what libogg does.

>
> Robert.
> Ps.: I did not find an ogg-only list, I hope, I'm not offtopic here.
>

This is as good a place as any...

Mike



More information about the Theora-dev mailing list