[ogg-dev] ogg dirac granulepos in oggz tools

[David Flynn]

On 2008-11-25, David Flynn <davidf+nntp at woaf.net> wrote:
> On 2008-11-23, Conrad Parker <conrad at metadecks.org> wrote:
>> 2008/11/24 David Flynn <davidf+nntp at woaf.net>:
>>> On a slightly unrelated note, i keep hitting the following error in
>>> liboggz when using the oggz tools on an ogg dirac stream:
>>>
>>> /home/davidf/project/liboggz/src/liboggz/oggz.c:202: oggz_close:
>>> Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed.
>> I expect that will be in the code that tries to calculate granulepos
>> when it is not present on the page, which is actually unecessary for
>> this mapping -- so I expect it will be straightforward to fix.
>> Of course the file will be necessary to debug it :-)
>
> Solved.  The ogg file in question had an EOS page with gp = UINT64_MAX
> and liboggz stashes all packets away in the packet_buffer until a gp is
> found.
>
> Hacking the muxer i was using to set the eos page to have a timestamp of
> 0 solves it.  I'll now need to make it sample-and-hold for the eos page.

Something perhaps to add to oggz-validate?  It isn't legal for:
  gp = UINT64_MAX  and  EOS bit set

Since, EOS bit is set on the final page,  and gp = UINT64_MAX implies
non final page.

NB, it is possible to have a final packet that spans multiple pages, it
is only the last page which should have the gp and EOS set. NB, unless
there are tiny page sizes, this shouldn't occur with the the ogg-dirac
mapping (it could if someone tries hard enough though).

This would probably need the above assertion to be solved too -- at end
of something, the packets hanging around in the buffer need to be
flushed so the various filter handlers can deal with them.

..david