[Vorbis-dev] copying an ogg stream

[illiminable]

----- 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
>> >middle...
>> >
>>
>> 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 
anyway.

>>
>> 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 
>> with
>> 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.

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 
sync point.

Cheers,

Zen.