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