[MPlayer-dev-eng] Re: [PATCH] theora support

[Monty]

> 1. keyframe detection in demux_ogg_seek should use the theora stream
>    handler's theora-state for properly determining keyframes
> 
>    theora's method of encoding keyframe information is unbelievably
>    stupid:

If you have first-class ogg demuxing, you get keyframes for free.  You
can seek to any keyframe, by number, in Olg(n) time (for files of a
few GB, that's still faster than decoding a frame), no syncpoint table
necessary.

If, however, the ogg demux is underpowered or an afterthought ("I
don't care about Ogg!  I just want the theora/vorbis/whatever
packets!") I could see why someone might be struggle/fight the
infrastructure.

If you have a specific scenario to offer why the granpos strategy is
'unbelievably stupid', I'll be happy to discuss it.  FWIW, that
strategy is not set in stone; however, the objections I've seen to it
so far have been wrongheaded.  (I personally have a few things in the
'con' column for the granpos method, but the common objections aren't
the ones I have).

> the granule pos of theora pckets is calculated like this:
>    (keyframeNo<<keyframeShift | interframeNo).  if the intermediated
>    frame number `interframeNo' is zero, you know that you've a key
>    frame.  unfortunately `keyframeShift' is NOT FIXED.  it's not even
>    stored directly in the stream header, instead you will have to
>    calculate the base-2 logarithm of `keyframe_frequency_force-1'
>    (theora/lib/toplevel.c:theora_decode_init).

That counts as 'stored in the frame header'.

>    currently my code just calculates `granulePos&0x1FF' and tests
>    whether it's zero.  there's some chance that this will make it skip
>    some keyframes or sync on a non-keyframe, but won't cause fatal
>    errors.

This is certain to break with the next release, but then again, next
release will likely see more bitstream format shift anyway.  If we're
lucky, it might see an early OggFile as well.

Monty
TD, xiph.org