Hi On Thu, Mar 02, 2006 at 10:38:54AM +0200, Oded Shimon wrote:
On Wed, Mar 01, 2006 at 03:19:40PM +0100, Michael Niedermayer CVS wrote:
CVS change done by Michael Niedermayer CVS
Update of /cvsroot/mplayer/main/DOCS/tech In directory mail:/var2/tmp/cvs-serv10365
Modified Files: mpcf.txt Log Message: add forward_ptr to syncpoint (+0.006% overhead) give syncpoint and frameheader their own checksums (worst case overhead increase <0.006%) fix filestructure so that extendability is restored move index_ptr to the fileend so that index packets arent a special case with their reserved_bytes position -> all packets follow the same structure now
remove "optional" word from info packets, they are not more optional then index packets
split index packets note, this is entirely optional and a muxer which has difficulty with it can always output a single index packet
remove the index MUST be at the file end if anywher rule, its not needed anymore as index_ptr will always be at the end
info frames must be keyframes
last info frame is the most correct
comments, flames?
I'm not strongly against anything here, but it would've been better if you would have showed the patch (and resolved conflicts) before committing... :/
i did post a patch and adapted it based on comments ...
index: - index_startcode f(64) - forward_ptr v max_pts v + syncpoint_start v
Is syncpoint_start necessary? Seems redundant to me. BTW, it is non obvious from this spec that the index is split by syncpoints and how to use, it should be elaborated better (by an entry for syncpoint_start perhaps..)
fixed
+file: + file_id_string + while(bytes_left > 8){
I'm a bit weirded out by this, In a very extreme and silly example, in a truncated NUT file you could loose the last frame because it (and the frame header) was smaller than 8 bytes...
cut randomly -> u very likely loose something as it has been cut in the middle cut after a frame -> why dont you just add 8 zero bytes then too if you already do parse things? anyway, if you and rich want we could add the thing back in the index but before the reserved bytes and store a index packet with 0 syncpoints and reserved_bytes always none at the end or do you have a alternative idea?
@@ -474,12 +508,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
Like I said, this should be a NUT flag...
and i disagree
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 2*max_distance or its
I still feel this should be a seperate variable, the only reason you gave so far against it is that poor demuxers won't be able to decide... And IMO that's a very poor argument...
every additional field adds complexity, what do we gain here with that field? personally i would fix max_distance and not store it at all, as i fear people will set it to random values
@@ -612,11 +645,8 @@ that EOR. EOR is unset by the first keyframe after it.
index_ptr - Length in bytes of the entire index, from the first byte of the - startcode until the last byte of the checksum. - Note: A demuxer can use this to find the index when it is written at - EOF, as index_ptr will always be 12 bytes before the end of file if - there is an index at all. + absolute location in the file of the first byte of the startcode of the + first index packet, or 0 if there is no index
This would be a silly argument, but it does limit the filesize to 64 bits... Doesn't matter, it's not very different from limiting the index to 64 bits...
if its >64bits just store the 64 least significant, and look at the closest such point from the end -> identical to relative ptr note, the alternative of putting a "v" style index_ptr in an zero syncpoint index at the end would solve this though IMO the complexity is not worth it
Info tags: ---------- @@ -630,6 +660,8 @@ file. Positive chapter_id's are real chapters and MUST NOT overlap. Negative chapter_id indicate a sub region of file and not a real chapter. chapter_id MUST be unique to the region it represents. + chapter_id n MUST not be used unless there are at least n chapters in the + file
Could you explain this, I'm confused...
yes, we dont want to use arbitrary precission math for chapter ids without this rule, someone could simply come up with the idea of using strings as chapter ids, which wont be fun for most demuxers [...] -- Michael