[ogg-dev] [Schrodinger-devel] ogg dirac granulepos in oggz tools

[David Flynn]

On 2008-11-14, Conrad Parker <conrad at metadecks.org> wrote:
> Should oggz-comment be modified to disallow modification of Dirac
> streams, ie. does Ogg Dirac never contain VorbisComment metadata?

Correct; there is no metadata handling capability in the current
mapping spec.

> It seems oggz chop, merge and sort will need some attention to deal
> with the Dirac granulepos and dependency ordering, so let's leave them
> for the next release.

ok. -- may be worth having them 'warn' if they are operating on
something containing oggdirac.

>
> As of changeset:3782, oggz-validate reports only this one error for that file:
>
> conrad at chichai:~/share/dirac$ oggz validate sage-640x360.ogg
> sage-640x360.ogg: Error:
> 00:02:36.077: serialno 1763535876: Granulepos decreasing within track

Ok, that is due to the invalid granulepos in the EOS page (the actual
value doesn't make sense -- and is infact invalid (see in a moment))

The mapping spec sets two bits (8 & 30) to be zero.  It may be worth
checking for them (if the GP64 isn't -1).  The GP64 of the EOS page
in the sage- stream doesn't pass this test.

Infact, i was wondering why that granulepos looks so wrong:
00:02:36.077: -362377 -> (pt:7484,dt:0,dist:65399,delay:7484)

the way i calculated dt in oggz is actually redundant.  dt is defined
to be: dt=pt-delay; and is contained in the top 32bits of GP64, so
if GP64 is very -ve, why is dt=0?

Answer: because pt="GPH+L">>9 relies on the two zero bits being set
so that any overflow in adding dist_l and dist_h together don't affect
pt.

To summarise, the value of dt calculated in oggz_tools should be
identical to the top 32 bits of GP64.  If that fails, The two
protection bits havn't been cleared correctly.

> I modified the packet ordering check to not take the timestamp of
> Dirac packets into account (changeset:3782).

Ok, thanks.