Re: Theora packets with granulepos of -1

salsaman <[email protected]>
Newsgroups gmane.comp.multimedia.ogg.theora.devel
Message-ID <[email protected]>
On Tue, Feb 24, 2009 at 10:10 AM, [email protected]
<[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.