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? - ods15