[ogg-dev] eos on continued page

[Conrad Parker]

Hi,

I'm working on a new ogg file chopper (porting 'hogg chop' to C).
These work pagewise, ie. they just copy the pages that are needed from
the input to the output bitstream.

I'm modifying the last page in the output bitstream so that it has the
eos flag set. The last page is always one that has a granulepos set
(that of the last packet finishing on that page). But let's say it
subsequently contains an incomplete packet, like this (from 'hogg
pagedump' of the output file):

0x0013ec0c: Theora serialno 2127823547, granulepos 494|7 (cont)
(incplt) *** eos: 4223 bytes
        [665,1605,1653,255]

That list specifies the segment lengths. I would have expected the eos
to refer to the same packet that the granulepos refers to, ie. the
segment of length 1653.
However, when later reading this file via libogg, no packets in that
track are marked as eos, and hence it fails oggz-validate.

RFC3533 and framing.html both simply say:
header_type_flag bit 0x04: set: this is the last page of a logical
bitstream (eos)

Is this a bug in libogg (should it assign eos to the last completed
packet on the page marked eos), or in the specification (should it say
that the last page must not contain any incomplete packets, in which
case a page chopper will have to rewrite the last page and remove
them)?

cheers,

Conrad.