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.