On 25-Feb-08, at 9:34 AM, xiphmont@xiph.org wrote:> I'd say both; libogg should ignore the incomplete packet or flag a > structural error, and the spec should be clarified.I guess libogg should return -1 if you try to ogg_stream_packetout() after the eos packet. The eos flag pretty clearly applies to the *page* not the packet, so I think how that gets translated into the corresponding ogg_packet structure is a matter for the libogg api documentation, not the spec. -r
On 26/02/2008, Ralph Giles <giles@xiph.org> wrote:> On 25-Feb-08, at 9:34 AM, xiphmont@xiph.org wrote: > > > I'd say both; libogg should ignore the incomplete packet or flag a > > structural error, and the spec should be clarified. > > I guess libogg should return -1 if you try to ogg_stream_packetout() > after the eos packet. > > The eos flag pretty clearly applies to the *page* not the packet, so > I think how that gets translated into the corresponding ogg_packet > structure is a matter for the libogg api documentation, not the spec.ok. If the correct behaviour should be to ignore the incomplete packet, that should also be clarified in the spec. I'd find it useful if it was not considered a structural error, as it allows us to very simply chop files apart and put them back together. The eos flag on the page is then a very clear way of saying to ignore the extra data during decode. As far as the libogg API is concerned, I reckon it should also set op->e_o_s on the last completed packet on a page marked eos. cheers, Conrad.
On 25-Feb-08, at 3:42 PM, Conrad Parker wrote:> ok. If the correct behaviour should be to ignore the incomplete > packet, that should also be clarified in the spec.Fair enough. What if no packet ends on the eos page? What about additional pages after the eos page?> I'd find it useful if it was not considered a structural error, as it > allows us to very simply chop files apart and put them back together. > The eos flag on the page is then a very clear way of saying to ignore > the extra data during decode.There general idea with Ogg has been to distinguish non-fatal from fatal errors. libogg reports these by returning -1 while still returning the next valid bit of data. -r
Posted it to trac bug tracking at https://trac.xiph.org/ticket/1308 and to http://wiki.xiph.org/index.php/RFC_3533_Errata. Cheers, Silvia. On Tue, Feb 26, 2008 at 10:42 AM, Conrad Parker <conrad@metadecks.org> wrote:> On 26/02/2008, Ralph Giles <giles@xiph.org> wrote: > > On 25-Feb-08, at 9:34 AM, xiphmont@xiph.org wrote: > > > > > I'd say both; libogg should ignore the incomplete packet or flag a > > > structural error, and the spec should be clarified. > > > > I guess libogg should return -1 if you try to ogg_stream_packetout() > > after the eos packet. > > > > The eos flag pretty clearly applies to the *page* not the packet, so > > I think how that gets translated into the corresponding ogg_packet > > structure is a matter for the libogg api documentation, not the spec. > > ok. If the correct behaviour should be to ignore the incomplete > packet, that should also be clarified in the spec. > > I'd find it useful if it was not considered a structural error, as it > allows us to very simply chop files apart and put them back together. > The eos flag on the page is then a very clear way of saying to ignore > the extra data during decode. > > As far as the libogg API is concerned, I reckon it should also set > op->e_o_s on the last completed packet on a page marked eos. > > cheers, > > Conrad. > _______________________________________________ > ogg-dev mailing list > ogg-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/ogg-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/ogg-dev/attachments/20080226/40e34e69/attachment.htm