On Sat, Mar 18, 2006 at 12:06:37PM +0100, Michael Niedermayer wrote:
- It's not clear whether limits like max_distance and max_pts_difference take effect when the difference is > the limit, or when the difference is >= the limit. This must be specified one way or the other, and should be consistent between all the limits of this sort for the sake of simplicity.
agree
OK. Any preference which way? I can make a patch addressing these issues if you like but it won't be for a couple days.
- Is file_id_string desirable? There was a question about this at one point and I don't know if it was resolved. I don't really care one way or the other.
A. file_id_string at the begin B. no file_id_string at the begin
B has slightly lower complexity, A will help identifying the file if you are an idiot and open it in a text editor iam _slightly_ in favor of B
OK, so maybe change this.
- version 2 must be incremented for freeze/final.
agree
OK, adding this to the list of things to change.
- reserved_count can only be specified in the framecode, not explicitly in the frame header.
wither we: reserved_count -> reserved_count_plus1 and if(reserved_count_plus1[frame_code]==0) reserved_count_plus1[frame_code] v or we add a flag a flag seems better but inconsistant with how stream_id is coded ill post a suggested solution soon
I'm happy with the flags changes that were made, except that maybe more unlikely flags should be moved to above bit 6.
- We need a spec for what goes in the fourcc field, especially for audio, but it may also be an issue for video. Are XVID, DIVX, DX50, etc. valid or is MP4S the only valid MPEG4-ASP fourcc?
i dont care, a fourcc -> codec_id map is not that hard to add to a player
Hmm, I'm undecided on what's best...
- The correct spec for decode_delay is still missing. It just says "decode_delay MUST NOT be set higher than necessary for a codec." which is ambiguous and actually incorrect in the case of an mpeg4 stream without low_delay but with no B frames actually present. I've drafted possible wordings for a correct requirement on IRC before and I think Michael has written a corrected version too.
hmm, now if i could only remember it ...
My version said something to the effect that decode_delay is not a derived property of the pts sequence but a property defined by the compression specification or a relevant supplement (if we acknowledge that some ill-specified formats like Xiph codecs might require supplemental specs for storage in non-incestuous containers), and that the value of decode_delay in the NUT file MUST match the codec's idea of delay. Rich