ogg dev - May 2010 - Fwd: Skeleton 4.0 draft, help with Dirac fields please!

On 10 May 2010 23:20, Chris Pearce <chris at pearce.org.nz> wrote:
> The granulepos radix was something that Conrad and Ralph were talking about
> at FOMS2010. I don't know how it's supposed to be used, or why we
need it.
> It was supposed to be needed for Dirac? Maybe Ralph or Conrad can remember?
> If not, we should remove it. There's no point in adding a poorly
spec'd
> field that no one will use.
Right, so adding the 'granulepos radix' was based on my recollection
of a draft of the Ogg Dirac mapping. That version split the
granlulepos value into three parts to represent the reordering depth
as well as the offset to the start of the access unit. Since we record
the (variable) split position between the two granulepos parts in the
theora scheme, I thought we should add a field to document both for
Dirac. The field would just be zero for non-reordering codecs like
Theora.

However, looking at David's most recent draft* the current scheme is
more complicated than that, with the three parts split into four
pieces to achieve better compatibility with muxers which only know the
theora scheme. In any case, everything is fixed width, so we can just
record the fixed 'granule shift' of 22 bits in the current skeleton
field and things will be fine as far as Dirac goes.

The question then becomes how well the Dirac mapping would work for
other reordering codecs, and whether we want to add two (or three!)
additional granulepos interpretation fields to the fishbone spec in
case other codecs want to make different resolution tradeoffs.

 -r

* http://diracvideo.org/download/mapping-specs/dirac-mapping-ogg-1.0.pdf

> However, looking at David's most recent draft* the current scheme is
> more complicated than that, with the three parts split into four
> pieces to achieve better compatibility with muxers which only know the
> theora scheme. In any case, everything is fixed width, so we can just
> record the fixed 'granule shift' of 22 bits in the current skeleton
> field and things will be fine as far as Dirac goes.
>
> The question then becomes how well the Dirac mapping would work for
> other reordering codecs, and whether we want to add two (or three!)
> additional granulepos interpretation fields to the fishbone spec in
> case other codecs want to make different resolution tradeoffs.
I think we should stop retconning and finally set rules--- if we're
going to declare the granpos parameters in the header, then we have to
take away the infinitely flexible mappings.

Monty

On 11 May 2010 11:45, Monty Montgomery <monty at xiph.org> wrote:
> I think we should stop retconning and finally set rules--- if we're
> going to declare the granpos parameters in the header, then we have to
> take away the infinitely flexible mappings.
I don't disagree, but while of the alternatives I suggested do you favour?

 -r

Hi Guys & Gals,

I need you guys to decide whether we want to include extra granulepos 
fields to Skeleton 4. Given the underwhelming discussion regarding this, 
I'm guessing the need and/or desire for these fields isn't really there.

Firefox 4 betas are fast approaching, and if we're to include OggIndex 
support (and we want OggIndex support!) we need the Skeleton 4 format 
nailed down... So... I suggest we don't bother adding these extra 
granulepos related fields the Skeleton 4, and if the need and/or desire 
for these fields becomes clear in future we can add these fields to the 
fisbone packets in a Skeleton 4.x revision instead. The fisbone packet 
has a message-header-offset field specifically to allow such fields to 
be added in a backwards compatible way.

Does that sound a reasonable approach?


All the best,
Chris P.

Chris Pearce wrote:
>   Hi Guys & Gals,
> 
> I need you guys to decide whether we want to include extra granulepos 
> fields to Skeleton 4. Given the underwhelming discussion regarding this, 
> I'm guessing the need and/or desire for these fields isn't really
there.
I haven't commented mostly because I don't know what Monty's plans
for a
"grand unified granpos scheme" are. All of this is mostly in his head
right now, and he needs to be the one to provide feedback.