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'll supply an example file tomorrow if that would be of help. > > Any thoughts?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 :-) thanks, Conrad.
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. I do find that a bit ugly -- using a magic value in a timestamp to imply that no packet ends[1] -- surely it is better to use the segment table? There are times that a non dated packet is the easiest way to transmit something and to let the decoder sort out the missing timestamp. Unless i've missed the fact that it is being stashed to allow for timestamp interpolation? [1] yes, the rfc alludes to that. ..david
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