On Wed, Mar 01, 2006 at 01:50:44PM +0100, Michael Niedermayer wrote:
On Wed, Mar 01, 2006 at 06:15:44AM +0200, Oded Shimon wrote:
if (!eof) while(next_code != main_startcode){ - if(next_code == syncpoint_startcode) - syncpoint + if(next_code == syncpoint_startcode){ + prolog, syncpoint, epilog + } frame + reserved_headers } }
Does this mean info packets can only come after headers?... What if the headers are large and the radio station wants to switch songs, repeat the entire headers and then the info packets?
the current nut has this limit too, iam perfectly fine with removing that, but IIRC rich at some point in the past wanted info only after stream headers or something like that
The current NUT has info streams and info packets always apply globally, so it makes sense in current NUT... Hmm, I do suggest a rule "all info packets with chapter_id>=0 MUST come after main headers" (and not arbitrarily between frames...)
@@ -476,12 +500,15 @@ 1 is_key if set, frame is keyframe 2 end_of_relevance if set, stream has no relevance on presentation. (EOR) + 4 has_checksum if set then the frame header contains a checksum
Maybe this should be a NUT-flag?
NUT-flag?
There are stream flags and nut flags. nut flags are 'msb coded size', 'invalid frame code' and 'coded stream flags'. The checksum flag sounds like a nut flag. (stream flags go on to the caller api, nut flags stay within the nut demuxer)
EOR frames MUST be zero-length and must be set keyframe. All streams SHOULD end with EOR, where the pts of the EOR indicates the end presentation time of the final frame. An EOR set stream is unset by the first content frames. EOR can only be unset in streams with zero decode_delay . + has_checksum must be set if the frame is larger then 64kb or its
2*max_distance ?
ok
Actually, I'd go even further to suggest this as a per stream setting...
@@ -729,21 +743,30 @@ If an index is written anywhere in the file, it MUST be written at end of file as well.
+Each index packet SHOULD be <4kb, that way a demuxer can simply:
This is extremely hard to enforce, the index has 2 parts, the syncpoint positions and the keyframe pts stuff. The keyframe pts is usually pretty small so you could just stop when you reach 4kb when writing syncpoint positions, and hope that the other part doesn't grow past 4kb...
for(i=0; i<n; i+=step){ while(build index(i, step, 4kb)) step>>=1; write out }
build & write out can trivially be replaced by write & seek back within an IO buffer
Ah, ok that's good, didn't think of that. It still leave the problem of reading index (and truely, I dislike the added complexity for the questionable gain.) You said this "simplifies" building the index, because forward_ptr is unknown, and a 2 pass solution is messy. You solution for building the index requires building it MANY times.. Although I don't see either actions as messy at all, the first pass could be done using a "bit bucket" memory buffer, and the second pass would be to file out. though you might as well build it in memory alltogether, this is only for the muxer, nobody cares about 80kb memory usage for muxing... The 2 big problems I still have with this new index - index_ptr, and raising complexity of utility that copies index to begginning of file. Yes, both are rather "rediculous" and solvable issues, but WHY have these issues at all... We already disucssed that the likelyhood of loosing a little data in the index without loosing all of it is very little. Rich gave up his "advanced syncpoints" because they raised complexity greatly for very questionable gain... Index repetition is very useful, because you can have the index in 2 edges of the file, but IMO index splitting is hardly useful at all, you might as well just repeat the index twice in the end. And, I'll continue being redundant here, in noting that loosing the index is no great trajedy!... Even in cdroms, seeking without index was just fine! Admittedly slightly slower, but still in the vecinity of ~1 second per seek. Is this really worth it. - ods15