Hi On Sat, Feb 24, 2007 at 01:28:46PM +0200, Oded Shimon wrote:
It also includes some FIXME's he added... (I'm sending this patch for him due to mail server down...)
- ods15
[...]
keyframe A keyframe is a frame from which you can start decoding, a more exact definition is below - The nth frame is a keyframe if and only if frames n, n+1, ... in - presentation order (that are all frames with a pts >= frame[n].pts) can + The nth frame is a keyframe if and only if frames n, n+1, ... in + presentation order (that means all frames with a pts >= frame[n].pts) can be decoded successfully without reference to frames prior n in storage - order (that are all frames with a dts < frame[n].dts) - if no such frames exist (for example due to use of overlapped transforms - like the MDCT in an audio codec) then the definition shall be extended + order (that means all frames with a dts < frame[n].dts). + If no such frames exist (for example due to use of overlapped transforms + like the MDCT in an audio codec), then the definition shall be extended by dropping n out of the set of frames which must be decodable, if this
iam against this change [...]
+FIXME: The frame_code description is convoluted and incomprehensible. frame_code (f(8)) frame_code is an 8-bit field which exists before every frame, it can store part of the size of the frame, the stream number, the timestamp - and some flags amongst other things, what is not directly stored - in it but is needed is stored in various fields immediately after it - the values stored in it can be found in the main header - the value 78 ('N') is forbidden to ensure that the byte is always - different from the first byte of any startcode - a muxer SHOULD mark 0x00 and 0xFF as invalid to improve error - detection + and some flags amongst other things. What is not directly stored + in it but is needed is stored in various fields immediately after it. + The values stored in it can be found in the main header. + The value 78 ('N') is forbidden to ensure that the byte is always + different from the first byte of any startcode. + A muxer SHOULD mark 0x00 and 0xFF as invalid to improve error + detection.
i cant clarify it unless you are more specific [...]
+FIXME: What does "at the frame header" mean? + 5 FLAG_SIZE_MSB If set data_size_msb at the frame header, + otherwise data_size_msb is 0
if set data_size_msb is coded/stored at the frame header, otherwise data_size_msb is 0 [...]
+FIXME: What is a 'sub region'? + A negative chapter_id indicates a sub region of the file and not a real chapter. chapter_id MUST be unique to the region it represents.
s/sub region/region/ [...]
+FIXME: Does this have to be lowercase? "SourceContainer" "nut", "mkv", "mov", "avi", "ogg", "rm", "mpeg-ps", "mpeg-ts", "raw"
yes we would have to unfreeze the spec and break compatibility to change it and i prefer lower case anyway :) [...]
+FIXME: Does the following line have a meaning here? the language code
no [...]
+FIXME: This description is confusing, after 2^x *and* end of file??? Each set of repeated headers not at the beginning or end of the file SHOULD -be stored at the earliest possible position after 2^x where x is -an integer and the file end, so the headers may be repeated at 4102 if that is -the closest position after 2^12=4096 at which the headers can be placed +be stored at the earliest possible position after 2^x where x is an integer +and the end of the file. So the headers may be repeated at 4102 if that is +the closest position after 2^12=4096 at which the headers can be placed.
Each set of repeated headers not at the beginning or end of the file SHOULD be stored at the earliest possible position after 2^x where x is an integer. And at the end of the file. So the headers may be repeated at 4102 if that is the closest position after 2^12=4096 at which the headers can be placed. yeah i know its not well said, i just splited it to make the intent clear ... [...]
-in the absence of a valid header at the beginning, players SHOULD search for +FIXME: Where is the syncpoint included? +In the absence of a valid header at the beginning, players SHOULD search for backup headers starting at offset 2^x; for each x players SHOULD end their -search at a particular offset when any startcode is found (including syncpoint) +search at a particular offset when any startcode is found (including syncpoint).
in the set of startcodes at which the demuxer should stop [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.