[theora-dev] Theora packets with granulepos of -1

salsaman salsaman at gmail.com
Tue Feb 24 05:23:35 PST 2009


On Tue, Feb 24, 2009 at 10:10 AM, ogg.k.ogg.k at googlemail.com
<ogg.k.ogg.k at googlemail.com> wrote:
>> Well, your procedure for seeking is dangerously wrong for a start. If
>> you follow your advice, one would begin decoding from the _last_ page
>> of the previous keyframe - as opposed to the first page (or as near as
>> posible) of the keyframe.
>
> Could you be more specific about what is wrong ? This page seems to
> be a high level overview of seeking, I believe Conrad had posted a
> finer grained list of steps to ogg-dev a few months ago, and I thought
> this had been copied to the wiki, but maybe not (or somewhere else).
>

You need to seek to a granulepos *before* the keyframe, and start
counting from there. Otherwise you will not decode the keyframe
properly.



> Bear in mind that the granpos effectively seeked to is strictly earlier
> than the target - an error I've made in the past, leading me to believe
> decoding would start slightly too late.

It needs to be earlier than the target's keyframe, not just earlier
than the target. That is why I do a two pass search - first to find
the target keyframe, then to find the highest gpos before that
keyframe.



>
>> Also there is no mention of -1 granulepos, the value of the first
>> keyframe, or of how to calculate the keyframe shift.
>
> -1 granpos is for continued pages, so you wouldn't consider them for
> seeking since their granpos is unknown.
>

Right, but the meaning of the -1 should be mentioned somewhere....hmmm
now where have I seen a thread asking about this...;-)

> The value of the first keyframe is irrelevant for seeking. The corner
> cases are seeking exactly to one bound (eg, seeking to the start of
> the stream, in which case you don't find a valid granpos < target),
> and seeking out of the bounds of your stream. I don't think you need
> to worry about the first granpos in each case.
>

It is needed as noted. Imagine you are seeking for frame 1 in the clip.



> The keyframe shift is a given, its calculation is codec dependent.
>

OK.


Gabriel.


More information about the theora-dev mailing list