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

2008/11/26 David Flynn <davidf+nntp at woaf.net>:
>>>> http://trac.annodex.net/changeset/3801
>>>
>>> I'll test this shortly.
>
> Ok, i've tested muxing some audio and video together and that works
fine.
> woo.
great, thanks :-)

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:

conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o
sage-7-11.ogv ../dirac/sage-640x360.ogg
conrad at chichai:~/share/oggz-chop$ oggz dump sage-7-11.ogv |grep
serialno | head -n 20
00:00:00.000: serialno 1762443388, granulepos 0, packetno 0 *** bos: 64 bytes
00:00:00.000: serialno 1763535876, granulepos
(pt:0,dt:0,dist:0,delay:0), packetno 0 *** bos: 39 bytes
00:00:00.000: serialno 0719746932, granulepos 0, packetno 0 *** bos: 30 bytes
00:00:00.000: serialno 0719746932, calc. gpos 0, packetno 1: 75 bytes
00:00:00.000: serialno 0719746932, granulepos 0, packetno 2: 3.742 kB
00:00:00.000: serialno 1762443388, granulepos 0, packetno 1: 80 bytes
00:00:00.000: serialno 1762443388, granulepos 0, packetno 2: 81 bytes
00:00:00.000: serialno 1762443388, granulepos 0, packetno 3 *** eos: 0 bytes
00:00:06.923: serialno 1763535876, granulepos
(pt:334,dt:332,dist:51,delay:2), packetno 2: 1.685 kB
00:00:06.965: serialno 1763535876, granulepos
(pt:344,dt:334,dist:52,delay:10), packetno 3: 16.928 kB
00:00:07.007: serialno 1763535876, granulepos
(pt:338,dt:336,dist:53,delay:2), packetno 4: 1.529 kB
00:00:07.048: serialno 1763535876, granulepos
(pt:340,dt:338,dist:54,delay:2), packetno 5: 1.761 kB
00:00:07.090: serialno 1763535876, granulepos
(pt:342,dt:340,dist:55,delay:2), packetno 6: 1.576 kB
00:00:06.857: serialno 0719746932, calc. gpos 329152, packetno 4: 1 byte
00:00:06.878: serialno 0719746932, calc. gpos 330176, packetno 5: 1 byte
00:00:06.900: serialno 0719746932, calc. gpos 331200, packetno 6: 1 byte
00:00:06.921: serialno 0719746932, calc. gpos 332224, packetno 7: 1 byte
00:00:06.942: serialno 0719746932, calc. gpos 333248, packetno 8: 1 byte
00:00:06.954: serialno 0719746932, calc. gpos 333824, packetno 9: 1 byte
00:00:06.957: serialno 0719746932, calc. gpos 333952, packetno 10: 45 bytes

However I don't know if this output is correct. What it is supposed to do
is create a file containing all packets for display between 7 and 11 seconds,
and to include all packets required to decode those, ie. all reference
frames that are required by packets from 7s onwards.

The original file included two more Dirac packets immediately prior to
those included
in the chopped output, but I don't know how to tell if these are
required reference
frames for those from 7s (or from 6.965s) onwards:

conrad at chichai:~/share/oggz-chop$ oggz dump ../dirac/sage-640x360.ogg
|grep serialno
...
00:00:06.814: serialno 0719746932, calc. gpos 327104, packetno 406: 1 byte
00:00:06.836: serialno 0719746932, granulepos 328128, packetno 407: 1 byte
00:00:06.840: serialno 1763535876, granulepos
(pt:330,dt:328,dist:49,delay:2), packetno 168: 1.603 kB
00:00:06.881: serialno 1763535876, granulepos
(pt:332,dt:330,dist:50,delay:2), packetno 169: 1.683 kB
00:00:06.923: serialno 1763535876, granulepos
(pt:334,dt:332,dist:51,delay:2), packetno 170: 1.685 kB
00:00:06.965: serialno 1763535876, granulepos
(pt:344,dt:334,dist:52,delay:10), packetno 171: 16.928 kB
00:00:07.007: serialno 1763535876, granulepos
(pt:338,dt:336,dist:53,delay:2), packetno 172: 1.529 kB
00:00:07.048: serialno 1763535876, granulepos
(pt:340,dt:338,dist:54,delay:2), packetno 173: 1.761 kB
00:00:07.090: serialno 1763535876, granulepos
(pt:342,dt:340,dist:55,delay:2), packetno 174: 1.576 kB
00:00:06.857: serialno 0719746932, calc. gpos 329152, packetno 408: 1 byte
00:00:06.878: serialno 0719746932, calc. gpos 330176, packetno 409: 1 byte
...

So:
 - is the current output correct?
 - 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?

Conrad.

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:
> 
> conrad at chichai:~/share/oggz-chop$ oggz chop -s 7 -e 11 -o
> sage-7-11.ogv ../dirac/sage-640x360.ogg
> conrad at chichai:~/share/oggz-chop$ oggz dump sage-7-11.ogv |grep
> serialno | head -n 20
> 00:00:00.000: serialno 1762443388, granulepos 0, packetno 0 *** bos: 64
bytes
> 00:00:00.000: serialno 1763535876, granulepos
> (pt:0,dt:0,dist:0,delay:0), packetno 0 *** bos: 39 bytes
> 00:00:00.000: serialno 0719746932, granulepos 0, packetno 0 *** bos: 30
bytes
> 00:00:00.000: serialno 0719746932, calc. gpos 0, packetno 1: 75 bytes
> 00:00:00.000: serialno 0719746932, granulepos 0, packetno 2: 3.742 kB
> 00:00:00.000: serialno 1762443388, granulepos 0, packetno 1: 80 bytes
> 00:00:00.000: serialno 1762443388, granulepos 0, packetno 2: 81 bytes
> 00:00:00.000: serialno 1762443388, granulepos 0, packetno 3 *** eos: 0
bytes
> 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.

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.



dave...

On 2008-12-04, Conrad Parker <conrad at metadecks.org>
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:
Chopping is more difficult.  It needs to be done based upon the
presentation time which isnt in order.
> So:
>  - is the current output correct?
Need to check.  The best way is to compare the output of chopping a
non-reordered sequence and a reordered one.  NB, if you jump into the
middle of a dependency chain there will be a few extra pictures at the
start -- something which skeleton stuff might fix (when values for
the fields are decided)
>  - 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.

..david

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.