[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