[theora] Ogg Index A-mod

Chris Pearce chris at pearce.org.nz
Sun Apr 25 17:21:22 PDT 2010

On 24/04/2010 1:32 a.m., Benjamin M. Schwartz wrote:
>> Would you expect the granulepos scaling shift to be equal to the
>> >  granuleshift for theora streams, at least initially? Have you given any
>> >  thought to how to determine good values for the shifts and Rice parameters?
> The spec suggests that for most streams a granularity of 2 seconds or 64
> KB is sufficient.  I think that corresponds to a granulepos scaling shift
> of granuleshift+log2(2 seconds / granulerate), and a byte offset scaling
> shift of log2(64K) = 16.  That quantization may be a touch excessive;
> maybe 1 second and 32 KB would be sufficient.  For selecting the Rice
> parameter, the optimum parameter is log2(mean(data)) up to rounding.

So, for the granulepos, you suggest the scaling shift to be: 
granuleshift + log2(2 / granulerate)

For Theora streams this will be: granuleshift + log2(2 / frames_per_second)
log2(2 / frames_per_second) is going to be negative for streams with 
more than 2 frames per second.

For Vorbis streams this would be log2(2 / vorbis_info.rate), which is 
going to be negative.

Am I calculating this wrong? Or did you mean granuleshift + 
log2(granulerate / 2) ? I'm having trouble determining good values for 
these, and getting sensible encoded and decoded values...

We'd also have to be wary of compound errors, e.g. if a keypoint's 
a-mod-encoded offset decodes to some value less than it's actual value, 
the delta of all subsequent keyframes need to be adjusted to compensate, 
else any subsequent keypoint's offset will be incorrect by the sum of 
all errors of all keyframes which come before it. So a keypoint's 
offsets/granulepos will need to be delta'd from the offset/granulepos as 
decoded from its preceeding keypoint, not the previous keypoint/offset. 
The error would grow over time, and could result in poor compression for 
keypoints later on in long files.

Chris P.

More information about the theora mailing list