Re: further debugging of my ogg/theora decoder

On Thu, Nov 13, 2008 at 8:53 AM, salsaman <[email protected]> wrote:

>
>
> On Thu, Nov 13, 2008 at 7:37 AM, Conrad Parker <[email protected]>wrote:
>
>> 2008/11/13 salsaman <[email protected]>:
>> >
>> > 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)
>> >
>> > pass 2, calculate gpos from kframe, search for largest gpos < this
>> >
>> > then starting from that page:
>> >  - ignore any packets on that page
>> >  - count frames starting from the following page
>>
>> To clarify what you mean by "ignore" and "frames starting from the
>> following page":
>>
>
> Yes, sorry, I meant ignore any *complete* packets on that page.
>
>
>
>>
>> If you are always feeding these pages into ogg_stream_pagein(), and
>> always running ogg_stream_packetout() on them, then this should be
>> correct. In this case, "ignoring any packets on that page" means that
>> you retrieve all of the completed packets from that page with
>> ogg_stream_packetout(), but discard them. You then load the next page
>> with ogg_stream_pagein(). "Count frames starting from the following
>> page" means that you start counting from the next packet that is
>> returned by ogg_stream_packetout().
>>
>
> Right.
>
>
>
>>
>> >  - 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...)
>>
>> probably, but not guaranteed.
>
>
> My error here, I meant to say, "when we reach a page which produces kframe
> -1". Then we know that kframe`s packet begins on this page (or possibly the
> following page, if it is not a continuation).
>
>
>
>
>> As you're pulling packets out of the
>> stream anyway then you might as well just call
>> theora_packet_iskeyframe() which is cheap and will definitely give you
>> the correct info.
>>
>
> Shouldn`t be needed, since we are counting frames and we know which frame
> is the target`s keyframe already. Could be useful as a double check though.
>
>
>
>>
>> > - decode the next packet : this is our target frame
>> >
>> >
>> > Does that look correct ?
>>
>> Yes, as long as you are pushing all those pages into ogg_stream_pagein().
>>
>
> Right. ogg_stream_pagein() and ogg_stream_packetout().
>
> Gabriel.
>
>



I am finding something very strange in my test ogg files.

For example: I have a shift of 64, and I get a granulepos of 5130.

5130 == 80*64 + 10

which suggests that frame 80 is a keyframe.

However, if I start decoding from the beginning, the 81st frame is a
keyframe.

This suggests that the first frame should be 0. But if I try to search for
frame 0, it fails.

Everything is fine from frame 64 up, but the start is messed up.

I have found 2 partial workarounds for this:

a) add 1 to all frames - this works fine for continuous playback: 1, 2, 3,
4, etc.   but frames > 64 are 1 out when seeking

b) add 1 to all frames < 64 - this works fine for seeking, but messes up
continuous playback when frame 64 is reached

Any suggestions ?



Gabriel.
http://lives.sourceforge.net

_______________________________________________
theora-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/theora-dev