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

[Conrad Parker]

Hi David, David,

continuing the discussion from November, about chopping Ogg Dirac files:

2008/12/5 David Schleef <ds at entropywave.com>:
> On Fri, Dec 05, 2008 at 06:34:41AM +0900, Conrad Parker wrote:
>> So the last remaining tool to check is oggz-chop. I at first assumed it
>> would not work with Dirac's granulepos, but it seems to do something
>> vaguely useful:
>>
>> 00:00:06.923: serialno 1763535876, granulepos
>> (pt:334,dt:332,dist:51,delay:2), packetno 2: 1.685 kB
>
> The first picture should have a dist of 0, indicating that it's a place
> you can start decoding from.

ok, I implemented this method in r3879:

https://trac.annodex.net/changeset/3879

Please test :-)

> If you chopped an open GOP, you might get a few pictures after that
> which depend on earlier pictures, but they have presentation times
> before the key frame.  They will be ignored by the decoder.
>

ok, that's good; it seems this method should be correct, ie. it
ensures to provide at least all data required to present frames from
the chop start time.

2008/12/6 David Flynn <davidf+nntp at woaf.net>:
> On 2008-12-04, Conrad Parker <conrad at metadecks.org> wrote:
>>  - if not, how should the packets that a given packet depends on be determined,
>>    ie. how to determine reference frames? Is it possible to do so using only the
>>    granulepos encoding?
>
> If you find the picture at time (t), inspect the dist value in the
> decoded granule_position. then something equivalent to searching
> for a granule_position matching:
>  candidate_granpos >> 32 == (GP64 >> 32) - dist
>
> NB, dist / (field_coding+1) should be the number of packets to go
> backwards by.
>
> NB, don't keep repeating until you find dist=0, just do it once.

Is this suggesting a more efficient method (ie. will it include fewer
unnecessary pages at the start of the stream, compared to including
all pages from the most recent with dist=0?)

Conrad.