[ogg-dev] [Schrodinger-devel] ogg dirac granulepos in oggz tools
davidf+nntp at woaf.net
Fri Nov 14 15:02:29 PST 2008
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
> 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
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).
More information about the ogg-dev