On Tue, Nov 14, 2006 at 07:04:43PM +0200, Oded Shimon wrote:
On Sun, Nov 12, 2006 at 05:27:06PM +0200, Oded Shimon wrote:
On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
On Mon, Nov 06, 2006 at 01:44:19PM +0100, Michael Niedermayer wrote:
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
This is a new proposal: Basically identical to the previous one, only info packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of MUST NOT. Making the distinction between file and realtime streams less strict. Demuxers still SHOULD NOT search for info packets anywhere except after the main headers. I think this is most clean...
Comments?
Repost. ... 48 hour notice ...
Committed
OK, I'm sorry I committed this so hastily. You said you object until you have heard from Rich. I talked to Rich on IRC and he seemed apathetic on the issue and unwilling to reply on it. I changed my proposal to be somewhat saner with a less strict distinction between realtime and non-realtime streams, and you have not made any objection reply since. Can we discuss this now? - ods15