Re: further debugging of my ogg/theora decoder

salsaman wrote:
> Actually I have now realised it`s not that complicated, as you say, just
> counting frames and not caring about keyframes at all is the way to go.
> 
> My search runs in 2 passes:
> 
> pass 1, find largest gpos <= target - this gives us keyframe for target
> (note that a granulepos with k<= target, f>=target is also acceptable)

There's one corner case this doesn't handle, which is that the largest
gpos less than or equal to the target may not necessarily give you the
keyframe _immediately_ preceding the target, just one that is preceding.
This is again caused by the (unlikely) possibility that a keyframe could
be entirely contained in a page along with additional complete packets,
including possibly more complete keyframes.

I.e., you want to play frame 20. You find a page with gpos (16,18), and
a subsequent page with gpos (21,21). No other pages in between have a
gpos set (i.e., packets for frames 19, 20, and 21 all end on the same
page, and frame 21 is a keyframe). This would lead you to believe that
the keyframe for frame 20 is frame 16. But frame 19 could also be a
keyframe, and there is no way to tell from the page-level gpos values.

I'm not sure if this matters much, though. Decoding from any preceding
keyframe will still work.

> pass 2, calculate gpos from kframe, search for largest gpos < this
> 
> then starting from that page:
>  - ignore any packets on that page

Keep in mind that a continued packet could start on that page, and this
could be the packet you want (that ultimately ends several pages later).
It sounds like you understand this, but I want to be sure. You will have
to feed all of these pages---including the one where the continued
packet began---to your ogg_stream_state to get that packet out.

>  - count frames starting from the following page
>  - when we reach a page which produces (target -1), we know that is
> where kframe starts, so store that page offset (this is useful for
> playing backwards...)
> - decode the next packet : this is our target frame
> 
> 
> Does that look correct ?

With those caveats above, that all looks correct to me.