So Thomas and I have been trying to hash out the seek and mux issues
with grouped Ogg streams again, along with Conrad while he was here
in Barcelona after Guadec.
We'll put a longer proposal up later, but one question for the list:
Thomas has suggested changing the theora granulepos so the first data
packet the encoder spits out would be labeled 1/0 instead of 0/0, in
"frame count of the keyframe"/"distance to the last
keyframe". Thoughts?
If you think of the granulepos being derived from the ticks of a clock
(as is the case for all defined Ogg mappings) then Vorbis, Speex and
FLAC all use the *count* of ticks (or equivalently the count of playable
samples decodable) to define the granulepos, while theora currently uses
the *index* of the last playable sample (starting at zero).
Put another way, if you had a hypothetical packet with only one sample,
all our audio codecs would mark that packet with granulepos one, while
theora would use zero (modulo the shift of course). The audio codecs all
derive their granulepos from a sample count, while theora uses the
presentation time instead.
On the plus side for the current scheme, you can call
theora_granule_time() and directly compare the results with your
playback clock to determine whether to show the current frame. If
we change things you have to subtract one frame duration first.
On the plus side for changing the scheme, it's conceptually the
same as all the other codecs, which makes things easier to explain
and a more consistent model for future mappings to follow. It also
allows one to distinguish theora headers by their 0/* granulepos,
but this doesn't work for lapped audio codecs like vorbis.
Obviously, this introduces a one frame sync offset into all existing
theora files and/or playback applications. But most people won't notice,
and for most streams (i.e. non-icecast) it's easy to detect and fix by
rewriting the granulepos of all the theora packets. I think that's a
minor annoyance.
Anything we're not thinking of, or opinions either way?
-r
