[xine-devel] Re: [private] Re: [theora] support for theora in xine

[Andreas Heinchen]

Hello,

> On Tuesday, April 22, 2003, at 05:12 pm, Andreas Heinchen wrote:
> 
> > Are there other easy possibilities to see if the opp_packet is an
> > syncpoint? If not, could future versions of theora set the 
> > op.granulepos
> > for every keyframe? That would make seeking a lot easier.
> 
> There's a hack with the granulepos to facilitate streaming: the 
> lower-order bits are always zero. The field is treated something like a 
> fixed-point number, with the fractional part incremented on P frames 
> and the integral part incremented only for key frames. Where exactly 
> the radix is is encoded as part of the packet header (the log of 
> keyframe_frequency_force) so you'll still have to pass that up from the 
> decoder.
> 
> Hope that helps,

I investigated further. The problem with missed keyframes remains. Here
is a short sample of the output of my demuxer. It prints out the
framenumbers of each ogg.packet, that has granulepos set.

The stream used was created with the encoderexample.

eeking keyframe i 1056 p 18
seeking keyframe i 1075 p 8
seeking keyframe i 1084 p 10
seeking keyframe i 1095 p 8
seeking keyframe i 1104 p 10
seeking keyframe i 1115 p 6
seeking keyframe i 1124 p 1
seeking keyframe i 1124 p 10
seeking keyframe i 1135 p 6
seeking keyframe i 1144 p 3
seeking keyframe i 1144 p 8
seeking keyframe i 1153 p 7
seeking keyframe i 1153 p 11
seeking keyframe i 1165 p 2
seeking keyframe i 1165 p 8
seeking keyframe i 1165 p 15
seeking keyframe i 1165 p 22
seeking keyframe i 1165 p 26
seeking keyframe i 1192 p 6
seeking keyframe i 1201 p 1
seeking keyframe i 1201 p 8
seeking keyframe i 1201 p 15
seeking keyframe i 1201 p 23
seeking keyframe i 1201 p 30
seeking keyframe i 1201 p 38
seeking keyframe i 1201 p 46
seeking keyframe i 1201 p 55
seeking keyframe i 1201 p 63
seeking keyframe i 1265 p 4
seeking keyframe i 1265 p 12
seeking keyframe i 1265 p 18
seeking keyframe i 1293 p 4
seeking keyframe i 1302 p 7
seeking keyframe i 1302 p 19
seeking keyframe i 1302 p 29
seeking keyframe i 1302 p 35
seeking keyframe i 1347 p 3
seeking keyframe i 1347 p 26
seeking keyframe i 1384 p 6
seeking keyframe i 1402 p 0

The first iframe the decoder could have used was 1067 (1075-8). But that
hadn't granulepos set, so the demuxer missed it (currently I am looking
for pframe==0). Instead it catched another keyframe 335 frames (13,4
seconds) later.

There are several solutions to this problem:
1)decode the data in the demuxer during keyframeseeking (slow)
2)seek to any frame and display that (bad looking during/after seeking)
3)in future releases of theora, all ogg.packets containing an keyframe
will have a granulepos. If this is guaranteed, iframeseeking in demuxers
would be a lot easier.

What do you think about that?

Andreas Heinchen

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.