[NUT-devel] Info packets in NUT stream (spec bugs?)

[Michael Niedermayer]

Hi

On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
> On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
> > On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
> > > On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
> > > > On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
> > > > > the big problem with simply allowing arbitrarily placed info is that it 
> > > > > makes the info useless for the normal nut file case as the info cannot be
> > > > > found its like a dvd with chapters but the information about where the
> > > > > chapters begin is stored at the begin of the chapters, you end up with
> > > > > a O(n) search ...
> > > > > so ive some concerns with just saying its ok for streaming, as that
> > > > > leads to nut files laying around which are encoded for streaming ...
> > > > 
> > > > The proposal I had for this is - info packets not written after main 
> > > > headers are only allowed in real time streaming, and must have 
> > > > chapter_id!=0, and any info packets written after main headers, both in 
> > > > file and in streaming scenario, MUST be repeated together with all main 
> > > > headers. No demuxer would have to search anything past main headers, any 
> > > > info packets given during demuxing is "information update". In the file 
> > > > scenario, all info must be written after the main headers, so no searching 
> > > > necessary.
> > > 
> > > hmm, rich what is your oppinion about that? iam unsure if iam against it
> > > or not ...
> > 
> > - ods15
> 
> Objections? Commit? 48 hour notice from now.

i object until i heard a comment from at least rich, comments from
everyone else are of course welcome too

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is