Hi, I have a question about the format of Theora bitstream header. It seems to me that there are differences between the specification[1] (version 2004 Oct 1) and its reference implementation in libtheora 1.0alpha3 released at 2004 Jun 1. I mean that... please refer to Section 6.2 'Identification Header Decode' in that specification[1] and the function '_theora_unpack_info()' included in 'lib/toplevel.c'[2] of libtheora 1.0alpha3. In developing some pure Java program[3], I had required to implement some function, which converts granulepos to time in pure Java, and needed to parse Theora header in pure Java. Now, I have followed the format implemented in libtheora 1.0alpha3, and I have done to implement that function and confirmed it works well. So, my question is 'is it really OK to ignore its formal specification?'. I have heard 'Theora I pecification' has been frozen and I hope that specification has not been updated yet. [1] http://www.theora.org/doc/Theora_I_spec.pdf [2] http://svn.xiph.org/trunk/theora/lib/toplevel.c [3] http://www.jcraft.com/jroar/ Thanks, -- ymnk
On Mon, Nov 01, 2004 at 01:36:40PM +0900, Atsuhiko Yamanaka wrote:> I mean that... please refer to Section 6.2 'Identification Header Decode' > in that specification[1] and the function '_theora_unpack_info()' > included in 'lib/toplevel.c'[2] of libtheora 1.0alpha3.Can you be more specific about the difference you found? The last 5 bits of the info header, which specify the chroma subsampling and some as yet undefined bits which must be zero are read but not checked by the alpha3 reference implementation. Otherwise they match as far as I know.> So, my question is 'is it really OK to ignore its formal specification?'.Well, no. They should match. If they do not then we need to discover whether it is a bug in the reference implementation or a bug in the specification document. Ideally you should write the the spec, but because the spec hasn't had much independent verification yet, it may contain some errors. -r
Hi, Thank you for prompt reply, +-From: Ralph Giles <giles@xiph.org> ----- |_Date: Sun, 31 Oct 2004 23:56:48 -0800 __ | |Can you be more specific about the difference you found? I have worried that I have misunderstood how to read that spec. That spec documentation says >Output parameters: >Name Type Size(bits) Signed? Description and restrictions >VMAJ Integer 8 No The major version number. >VMIN Integer 8 No The minor version number. >VREV Integer 8 No The version revision number. >FMBW Integer 16 No The width of the frame in macro blocks. >FMBH Integer 16 No The height of the frame in macro blocks. >NSBS Integer 32 No The total number of super blocks in a frame. >NBS Integer 36 No The total number of blocks in a frame. >NMBS Integer 32 No The total number of macro blocks in a frame. >PICW Integer 20 No The width of the picture region in pixels. >PICH Integer 20 No The height of the picture region in pixels. >PICX Integer 8 No The X offset of the picture region in pixels. >PICY Integer 8 No The Y offset of the picture region in pixels. on the other hand, _theora_unpack_info in SVN says as follows, >theora_read(opb,8,&ret); ci->version_major=(unsigned char)ret; >theora_read(opb,8,&ret); ci->version_minor=(unsigned char)ret; >theora_read(opb,8,&ret); ci->version_subminor=(unsigned char)ret; ... >theora_read(opb,16,&ret); ci->width=ret<<4; >theora_read(opb,16,&ret); ci->height=ret<<4; >theora_read(opb,24,&ret); ci->frame_width=ret; >theora_read(opb,24,&ret); ci->frame_height=ret; >theora_read(opb,8,&ret); ci->offset_x=ret; >theora_read(opb,8,&ret); ci->offset_y=ret; For example, in the implementation, NSBS, NBS, NMBS defined in spec are not expected in the header. Thanks, -- ymnk
On Mon, Nov 01, 2004 at 05:17:47PM +0900, Atsuhiko Yamanaka wrote:> For example, in the implementation, NSBS, NBS, NMBS defined in spec > are not expected in the header.Ah. Yes. The table at the beginning of section 6.2 is confusing. It describes the *Output parameters* of the header decode procedure given in that section, not the contents of the header itself. NSBS, NBS, and NMBS are all calculated from other fields that are stored in the bitstream header, as indicated by steps 21-23 of that section. Other sections of the specification refer to these values, so their calculation is specified here. Since the alpha 3 reference decoder does not support block-level quantization index switching, it does not need to calculate these. Regardless they do not occur in the bitstream header itself. I hope that clears up the confusion, -r