[Vorbis-dev] copying an ogg stream
ogg at illiminable.com
Wed Sep 22 20:19:31 PDT 2004
----- Original Message -----
From: "Monty" <xiphmont at xiph.org>
To: "illiminable" <ogg at illiminable.com>
Cc: "Christoph Rupp" <crupp at umc-web.de>; <vorbis-dev at xiph.org>
Sent: Wednesday, September 22, 2004 4:15 AM
Subject: Re: [Vorbis-dev] copying an ogg stream
> On Thu, Sep 23, 2004 at 12:31:01AM +0800, illiminable wrote:
>> ----- Original Message -----
>> From: "Christoph Rupp" <crupp at umc-web.de>
>> To: "illiminable" <ogg at illiminable.com>
>> Cc: <vorbis-dev at xiph.org>
>> Sent: Thursday, September 23, 2004 12:26 AM
>> Subject: Re: [Vorbis-dev] copying an ogg stream
>> >Hi Zen,
>> >illiminable wrote:
>> >>Why is it that you break the packets out of the page ?
>> >to set the e_o_s flag. i want to be able to cut off the file in the
>> Can't you do that directly on the page ? Or does it need to be packet
>> accurate ?
> Breaking out packets is neither wrong nor complicated. His appraoch
> is conceptually clean and easy to manage. I see no reason to
> discourage it.
The only reason i saw it as a potentialy better approach is that since most
of the packets don't have a granule pos... if the remux doesn't exactly
match the same page boundries, you either have to do codec level granule pos
calculation, or you end up with a heap of pages having -1 granule pos
>> Even if it does need to be packet accurate... only the last page need be
>> broken up.
>> If you only need page level accuracy... you can just add an empty page
>> the EOS flag set and the granule pos of the previous page... setting the
>> previous pages granule pos to -1.
> That would be pushing the bounds of what's legal under the spec. I
> don;t think the spec comes right out and says that intentionally
> neglecting granulepos entries where there should be a valid entry is
> illegal, but one could argue for the point. Of course, software had
> better behave either way.
Which reminds me actually... i found a bug in my mux, i'm not sure if the
same problem applies in libogg, but it's posible, so i figure i'll mention
It basically happens when muxing something with very large packets, ie very
high quality video. Assuming there is no audio stream.
Since the packets are so large compared to the average page size... almost
none of the pages actually have a granule pos. So i'm not sure if libogg has
a "forced granule pos" bit of code... basically where it ignores it's normal
page sizing algorithm and if a page with a granule pos hasn't been written
for x pages or y seconds it forces out a short page in order to provide a
More information about the Vorbis-dev