Re: further debugging of my ogg/theora decoder

On Wed, Nov 12, 2008 at 1:13 PM, salsaman <[email protected]> wrote:

> suppose I start decoding from a page with granulepos (kframe=x, frame =y)
> and I continue decoding in sequence until I reach the next page with a
> non-negative granulepos (kframe=a, frame=b). Is it possible that there could
> be another keyframe between x and a ? In other words, do "hidden" keyframes
> exist in the ogg stream, or is it safe to assume that every keyframe has at
> least one (non-negative) granulepos ?

It's possible, though unlikely.

> Let me give an example. Suppose I am seeking for frame 20. I find a
> granulepos of (18,22). Good, so I know that the keyframe is 18 + an offset
> of 2. So now I seek again to find the largest granulepos before 18. I find
> (10,12). Great.
> So I start decoding from (10,12) and I reach a keyframe. Can I assume this
> keyframe is 18, and then just decode two more frames ?

In this case, you know the answer, because if you know by counting
whether the keyframe you just found is frame 18, no? Or are you
worried about having the backpropagate the (10,12) to earlier packets
in that (10,12) page? You do have to do that, you can't assume there
isn't a 9,9 in there too.

> I don't fully understand this negative-granulepos setting. For example, I
> have a video file where the first 10 or so pages have negative gpos, and
> then I get a page with (keyframe=1, frame=5). So what happened to (1,1)
> (1,2) (1,3) and (1,4) ? Surely it cannot be the case that all 5 frames are
> produced on the last page ?

It's possible if, for example, the keyframe is huge, and then there
are only tiny changes recorded in the successive frames. So you get,
with )( marking page boundaries and | marking packet boundaries

(| part 1 of frame 1 )( part 2 of frame 1 )...
(part 10 of frame 1 | frame 2 | frame 3 | frame 4 | frame 5 | part 1
of frame 6)...

Since page 10 is the first page where a packet ends, it's the first to
get a non-(-1) granulepos. The granulepos it gets is of the last
packet that ends on that page, which is frame 5, so the granulepos is
1,5

It's also possible the file is just incorrectly muxed and some pages
that should have a granulepos don't.

 -r