On Wed, Mar 01, 2006 at 01:50:44PM +0100, Michael Niedermayer wrote:
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
I still favor having info streams separate for the reasons I explained in the other email.
@@ -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?
This flag pertains to the NUT structure, not the frame contents, so it belongs in the other flags if at all. Personally I don't like this approach and prefer the old way of doing syncpoint checksums as long as you can make it sufficiently extensible to your liking.
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
Why is it 2* ? Why not just max_distance?
solution is that it worked even after a seek or damage, it required no additional variable or context. Also, does the syncpoint rule of max_pts_distance still apply? or is it just this checksum rule.
the syncpoint max_pts_distance rule doesnt apply anymore
Yes, and IMO that's problematic.. The rule was very simple and good.
checksum crc32 checksum checksum is calculated for the area pointed to by forward_ptr not including the checksum itself (from first byte after the forward_ptr until last byte before the checksum).
You should probably mention what area the checksum of frame headers cover...
ok
Is a checksum of 1 byte really useful? IMO not. Considering that with your proposal a frame header for a 1-meg packet could still be just 1 byte (easy with CBR), this seems like it will not work. This is one reason I prefer the method of combining with syncpoints. Rich