ogg dev - Feb 2008 - Re: Updating the Ogg mapping for Dirac

On Thu, Feb 28, 2008 at 1:53 AM, Ralph Giles <giles@xiph.org>
wrote:
> On 27-Feb-08, at 10:44 PM, Conrad Parker wrote:
>
>  > Sure: I'm thinking about Ogg demuxers and seeking
implementations.
>  > These need to know the framerate in order to be able to interpret the
>  > granulepos in terms of time. If they did not have to extract that
from
>  > the sequence header, but could just read it directly out of le32
>  > fields in the bos page, there would be less room for error.
>
>  How is this better than reading he same info out of a fishbone packet?
The 'shim' paradigm does not use fishbone.  The Ogg spec currently
needs information necessary to interpret granulepos and granpos
indexing in the initial header...

Monty

On 28-Feb-08, at 10:16 AM, xiphmont@xiph.org wrote:
> The 'shim' paradigm does not use fishbone.  The Ogg spec currently
> needs information necessary to interpret granulepos and granpos
> indexing in the initial header...
As I understand it, that's not the argument for the custom header. If  
you can ask the codec, you can get all this information out of the  
Dirac sequence header. It contains exactly what the initial header of  
an Ogg stream is supposed to contain.

Instead, the argument is that, like with Vorbis, replicating the code  
to parse this information outside the codec is tedious (David said  
his diff was 143 lines) and it would be better for stand-alone remux  
applications like annodex if they could read the info directly. But I  
thought that was what Skeleton was for, with the additional advantage  
that it's stored in a codec-independent way.

  -r

On 2/28/08, Ralph Giles <giles@xiph.org> wrote:
> But I thought that was what Skeleton was for, with the additional advantage
> that it's stored in a codec-independent way.
Ah, yes.  Let's not forget that, theoretically, all Ogg Dirac data
should contain a Skeleton stream.  Whatever implementations that deal
with Ogg Dirac and do not care about this step are just wasting
everyone's time, because they will later have to be patched.  Not to
mention that for efficiency sake, it would be better to publish one
kind of files out there, instead of two kinds (those with and those
without).

Taking in consideration that Skeleton should always be present, it
should remove some of the burden on creating a specific mapping for
Dirac.

-Ivo