RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity

spelling/punctuation/grammar/wording improvements, no semantic changes 

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@22488 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
diego 2007-03-08 10:26:00 +00:00
parent a708559fe5
commit 495b5f46ef
1 changed files with 230 additions and 229 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

459
DOCS/tech/nut.txt
View File

@ -7,73 +7,72 @@ NUT Open Container Format 20061104
Intro:
======
NUT is a Free multimedia container format for storage of audio, video,
NUT is a free multimedia container format for storage of audio, video,
subtitles and related user defined streams, it provides exact timestamps for
synchronization and seeking, is simple, has low overhead and can recover
in case of errors in the stream
in case of errors in the stream.
other common multimedia container formats are AVI, OGG, Matroska, MP4, MOV
ASF, MPEG-PS, MPEG-TS
Other common multimedia container formats are AVI, Ogg, Matroska, MP4, MOV
ASF, MPEG-PS, MPEG-TS.
Features / goals:
(supported by the format, not necessarily by a specific implementation)
Simple
use the same encoding for nearly all fields
simple decoding, so slow CPUs (and embedded systems) can handle it
Simplicity
Use the same encoding for nearly all fields.
Simple decoding, so slow CPUs (and embedded systems) can handle it.
Extendible
no limit for the possible values of all fields (using universal vlc)
allow adding of new headers in the future
allow adding more fields at the end of headers
Extensibility
No limit for the possible values of all fields (using universal vlc).
Allow adding of new headers in the future.
Allow adding more fields at the end of headers.
Compact
~0.2% overhead, for normal bitrates
index is <100kb per hour
a usual header for a file is about 100 bytes (audio + video headers together)
a packet header is about ~1-5 bytes
Compactness
~0.2% overhead for normal bitrates.
The index is <100kb per hour.
A typical file header is about 100 bytes (audio + video headers together).
A packet header is about ~1-5 bytes.
Error resistant
seeking / playback without an index
headers & index can be repeated
damaged files can be played back with minimal data loss and fast
resync times
Error resistance
Seeking / playback is possible without an index.
Headers & index can be repeated.
Damaged files can be played back with minimal data loss and fast
resynchronization times.
The spec is frozen. All files following spec will be compatible unless the
spec is unfrozen.
The specification is frozen. All files following the specification will be
compatible unless the specification is unfrozen.
Definitions:
============
MUST the specific part must be done to conform to this standard
SHOULD it is recommended to be done that way, but not strictly required
MUST The specific part must be done to conform to this standard.
SHOULD It is recommended to be done that way, but not strictly required.
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
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
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 are all frames with a dts < frame[n].dts).
If no such frames exist (for example due to using 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
is still insufficient then n+1 shall be dropped, and so on until there is
a keyframe
every frame which is marked as a keyframe MUST be a keyframe according to
a keyframe.
Every frame which is marked as a keyframe MUST be a keyframe according to
the definition above, a muxer MUST mark every frame it knows is a keyframe
as such, a muxer SHOULD NOT analyze future frames to determine the
keyframe status of the current frame but instead just set the frame as
non keyframe
non-keyframe.
(FIXME maybe move somewhere else?)
pts
presentation time of the first frame/sample that is completed by decoding
Presentation time of the first frame/sample that is completed by decoding
the coded frame.
dts
of a frame is the time when it is input into a synchronous 1-in-1-out
decoder
The time when a frame is input into a synchronous 1-in-1-out decoder.
Syntax:
@ -96,7 +95,7 @@ name (text description)
[Optional notes]
The bitstream syntax elements have a tagname and a functional definition, they
are presented in a bottom up approach, again optional notes may follow and
are presented in a bottom-up approach, again optional notes may follow and
are reproduced in the tag description:
name: (optional note)
@ -166,10 +165,10 @@ file:
frame
}
the structure of an undamaged file should look like the following, but
The structure of an undamaged file should look like the following, but
demuxers should be flexible and be able to deal with damaged headers so the
above is a better loop in practice (not to mention it is simpler)
note, demuxers MUST be able to deal with new and unknown headers
above is a better loop in practice (not to mention it is simpler).
Note: Demuxers MUST be able to deal with new and unknown headers.
file:
file_id_string
@ -203,10 +202,10 @@ Common elements:
reserved_bytes:
for(i=0; i<forward_ptr - length_of_non_reserved; i++)
reserved u(8)
[a demuxer MUST ignore any reserved bytes
a muxer MUST NOT write any reserved bytes, as this would make it
[A demuxer MUST ignore any reserved bytes.
A muxer MUST NOT write any reserved bytes, as this would make it
impossible to add new fields at the end of packets in the future
in a compatible way]
in a compatible way.]
packet_header
startcode f(64)
@ -368,8 +367,8 @@ index:
info_packet:
stream_id_plus1 v
chapter_id s (Note due to a typo this was v
until 2006-11-04)
chapter_id s (Note: Due to a typo this was v
until 2006-11-04.)
chapter_start t
chapter_len v
count v
@ -411,8 +410,7 @@ Tag description:
file_id_string
"nut/multimedia container\0"
the very first thing in every nut file, useful for identifying nut
files
The very first thing in every NUT file, useful for identifying NUT files.
*_startcode (f(64))
all startcodes start with 'N'
@ -433,24 +431,24 @@ info_startcode (f(64))
0xAB68B596BA78ULL + (((uint64_t)('N'<<8) + 'I')<<48)
version (v)
NUT version. The current value is 3. All lower values are pre-freeze
NUT version. The current value is 3. All lower values are pre-freeze.
stream_count (v)
number of streams in this file
time_base_count (v)
number of different time bases in this file
this MUST NOT be 0
This MUST NOT be 0.
forward_ptr (v)
size of the packet data (exactly the distance from the first byte
after the packet_header to the first byte of the next packet)
every nut packet contains a forward_ptr immediately after its startcode
with the exception of frame_code based packets, the forward pointer
can be used to skip over the packet without decoding its contents
Size of the packet data (exactly the distance from the first byte
after the packet_header to the first byte of the next packet).
Every NUT packet contains a forward_ptr immediately after its startcode
with the exception of frame_code-based packets. The forward pointer
can be used to skip over the packet without decoding its contents.
max_distance (v)
max distance between startcodes. If p1 and p2 are the byte
maximum distance between startcodes. If p1 and p2 are the byte
positions of the first byte of two consecutive startcodes, then
p2-p1 MUST be less than or equal to max_distance unless the entire
span from p1 to p2 comprises a single packet or a syncpoint
@ -459,25 +457,25 @@ max_distance (v)
frame headers, should a chain of frame headers pass max_distance
without encountering any startcode.
syncpoints SHOULD be placed immediately before a keyframe if the
Syncpoints SHOULD be placed immediately before a keyframe if the
previous frame of the same stream was a non-keyframe, unless such
non-keyframe - keyframe transitions are very frequent
non-keyframe - keyframe transitions are very frequent.
SHOULD be set to <=32768
if the stored value is >65536 then max_distance MUST be set to 65536
SHOULD be set to <=32768.
If the stored value is >65536 then max_distance MUST be set to 65536.
This is also half the max frame size without a checksum after the
frameheader.
This is also half the maximum frame size without a checksum after the
frame header.
max_pts_distance (v)
max absolute difference of pts of new frame from last_pts in the
timebase of the stream, without a checksum after the frameheader.
Maximum absolute difference of the pts of the new frame from last_pts in
the timebase of the stream, without a checksum after the frame header.
A frame header MUST include a checksum if abs(pts-last_pts) is
strictly greater than max_pts_distance.
Note that last_pts is not necessarily the pts of the last frame
on the same stream, as it is altered by syncpoint timestamps.
SHOULD NOT be higher than 1/timebase
SHOULD NOT be higher than 1/timebase.
stream_id (v)
Stream identifier
@ -488,16 +486,16 @@ stream_class (v)
1 audio
2 subtitles
3 userdata
Note: the remaining values are reserved and MUST NOT be used
a demuxer MUST ignore streams with reserved classes
Note: The remaining values are reserved and MUST NOT be used.
A demuxer MUST ignore streams with reserved classes.
fourcc (vb)
identification for the codec
example: "H264"
MUST contain 2 or 4 bytes, note, this might be increased in the future
if needed
the id values used are the same as in avi, so if a codec uses a specific
fourcc in avi then the same fourcc MUST be used here
if needed.
The ID values used are the same as in AVI, so if a codec uses a specific
FourCC in AVI then the same FourCC MUST be used here.
time_base_num (v) / time_base_denom (v) = time_base
the length of a timer tick in seconds, this MUST be equal to the 1/fps
@ -515,7 +513,7 @@ time_base_num (v) / time_base_denom (v) = time_base
time_base_id (v)
index into the time_base table
MUST be < time_base_count
MUST be < time_base_count.
convert_ts
To switch from 2 different timebases, the following calculation is
@ -526,8 +524,8 @@ convert_ts
d1 = from_time_base_denom
d2 = to_time_base_num
timestamp = (ln/d1*sn + ln%d1*sn/d1)/d2
Note: this calculation MUST be done with unsigned 64 bit integers, and
is equivalent to (ln*sn)/(d1*d2) but this would require a 96bit integer
Note: This calculation MUST be done with unsigned 64 bit integers, and
is equivalent to (ln*sn)/(d1*d2) but this would require a 96 bit integer.
compare_ts
Compares timestamps from 2 different timebases,
@ -549,16 +547,16 @@ compare_ts
msb_pts_shift (v)
amount of bits in lsb_pts
MUST be <16
MUST be <16.
decode_delay (v)
size of the reordering buffer used to convert pts to dts
codecs which don't support b frames normally use 0
mpeg1/mpeg2 style codecs with b frames use 1
h264 style b pyramid uses 2
h264 and future codecs might need values >2
audio codecs generally use 0 (we aren't aware of any which doesn't
but its theoretically possible that one exists which needs it >0)
Size of the reordering buffer used to convert pts to dts.
Codecs which do not support B-frames normally use 0.
MPEG-1/MPEG-2-style codecs with B-frames use 1.
H.264-style B-pyramid uses 2.
H.264 and future codecs might need values >2.
Audio codecs generally use 0. (We are not aware of any, but it
is theoretically possible that a codec might need a value >0.)
decode_delay MUST NOT be set higher than necessary for a codec.
stream_flags (v)
@ -566,50 +564,50 @@ stream_flags (v)
1 FLAG_FIXED_FPS indicates that the fps is fixed
codec_specific_data (vb)
private global data for a codec (could be huffman tables or ...)
if a codec has a global header it SHOULD be placed in here instead of
at the start of every keyframe
the exact format is specified in the codec spec
for H.264 the NAL units MUST be formatted as in a bytestream
(with 00 00 01 prefixes)
Private global data for a codec (could be huffman tables or ...).
If a codec has a global header it SHOULD be placed in here instead of
at the start of every keyframe.
The exact format is specified in the codec specification.
For H.264 the NAL units MUST be formatted as in a bytestream
(with 00 00 01 prefixes).
codec_specific_data SHOULD contain exactly the essential global packets
needed to decode a stream, more specifically it SHOULD NOT contain packets
which contain only non essential metadata like author, title, ...
it also MUST NOT contain normal packets which cause the reference decoder
to generate any specific decoded samples
the encoder name and version, shall be considered essential as it is very
usefull to workaround possible encoder bugs
It also MUST NOT contain normal packets which cause the reference decoder
to generate any specific decoded samples.
The encoder name and version shall be considered essential as it is very
useful to work around possible encoder bugs.
The global headers MUST consist of the normal
sequence of header packets required for codec initialization, in the
order defined in the codec spec. An implementation MAY strip metadata and
other redundant information not necessary for correct playback from the
global headers as long as no incorrect values are stored and as long as
the striped result is not less valid per codec spec as before striping
the stripped result is not less valid per codec spec as before stripping.
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.
flags[frame_code], frame_flags (v)
Bit Name Description
0 FLAG_KEY if set, frame is keyframe
1 FLAG_EOR if set, stream has no relevance on
0 FLAG_KEY If set, the frame is a keyframe.
1 FLAG_EOR If set, the stream has no relevance on
presentation. (EOR)
3 FLAG_CODED_PTS if set, coded_pts is in the frame header
4 FLAG_STREAM_ID if set, stream_id is coded in the frame header
5 FLAG_SIZE_MSB if set, data_size_msb is at frame header,
otherwise data_size_msb is 0
6 FLAG_CHECKSUM if set then the frame header contains a checksum
7 FLAG_RESERVED if set, reserved_count is coded in the frame header
12 FLAG_CODED if set, coded_flags are stored in the frame header.
13 FLAG_INVALID if set, frame_code is invalid.
3 FLAG_CODED_PTS If set, coded_pts is in the frame header.
4 FLAG_STREAM_ID If set, stream_id is coded in the frame header.
5 FLAG_SIZE_MSB If set, data_size_msb at the frame header,
otherwise data_size_msb is 0.
6 FLAG_CHECKSUM If set, the frame header contains a checksum.
7 FLAG_RESERVED If set, reserved_count is coded in the frame header.
12 FLAG_CODED If set, coded_flags are stored in the frame header.
13 FLAG_INVALID If set, frame_code is invalid.
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
@ -622,52 +620,52 @@ flags[frame_code], frame_flags (v)
defined as below).
last_pts
the timestamp of the last frame with the same stream_id as the current
if there is no such frame between the last syncpoint and the current
frame then the syncpoint timestamp is used, see global_key_pts
The timestamp of the last frame with the same stream_id as the current.
If there is no such frame between the last syncpoint and the current
frame then the syncpoint timestamp is used, see global_key_pts.
stream_id[frame_code] (v)
if FLAG_STREAM_ID is not set then this is the stream number for the
frame following this frame_code
if FLAG_STREAM_ID is set then this value has no meaning
MUST be <250
If FLAG_STREAM_ID is not set then this is the stream number for the
frame following this frame_code.
If FLAG_STREAM_ID is set then this value has no meaning.
MUST be <250.
data_size_mul[frame_code] (v)
if FLAG_SIZE_MSB is set then data_size_msb which is stored after the
If FLAG_SIZE_MSB is set then data_size_msb which is stored after the
frame code is multiplied with it and forms the more significant part
of the size of the following frame
if FLAG_SIZE_MSB is not set then this field has no meaning
MUST be <16384
of the size of the following frame.
If FLAG_SIZE_MSB is not set then this field has no meaning.
MUST be <16384.
data_size_lsb[frame_code] (v)
the less significant part of the size of the following frame
this added together with data_size_mul*data_size_msb is the size of
the following frame
MUST be <16384
The less significant part of the size of the following frame.
This added together with data_size_mul*data_size_msb is the size of
the following frame.
MUST be <16384.
pts_delta[frame_code] (s)
MUST be <16384 and >-16384
if FLAG_CODED_PTS is set in the flags of the current frame then this
If FLAG_CODED_PTS is set in the flags of the current frame then this
value MUST be ignored, if FLAG_CODED_PTS is not set then pts_delta is the
difference between the current pts and last_pts
difference between the current pts and last_pts.
MUST be <16384 and >-16384.
reserved_count[frame_code] (v)
MUST be <256
MUST be <256.
data_size
the size of the following frame
data_size= data_size_lsb + data_size_msb*data_size_mul;
The size of the following frame.
data_size = data_size_lsb + data_size_msb * data_size_mul ;
coded_pts (v)
if coded_pts < (1<<msb_pts_shift) then it is an lsb
pts, otherwise it is a full pts + (1<<msb_pts_shift)
If coded_pts < ( 1 << msb_pts_shift ) then it is an lsb
pts, otherwise it is a full pts + ( 1 << msb_pts_shift ).
lsb pts is converted to a full pts by:
mask = (1<<msb_pts_shift)-1;
delta = last_pts - mask/2
pts = ((pts_lsb-delta)&mask) + delta
mask = ( 1 << msb_pts_shift ) - 1;
delta = last_pts - mask / 2
pts = ( (pts_lsb - delta) & mask ) + delta
lsb_pts
least significant bits of the pts in time_base precision
Least significant bits of the pts in time_base precision.
Example: IBBP display order
keyframe pts=0 -> pts=0
frame lsb_pts=3 -> pts=3
@ -680,33 +678,33 @@ lsb_pts
frame lsb_pts=4 -> pts=260
frame lsb_pts=2 -> pts=258
frame lsb_pts=3 -> pts=259
all pts's of keyframes of a single stream MUST be monotone
All pts values of keyframes of a single stream MUST be monotone.
dts
decoding timestamp
the dts of a frame is the timestamp of the first sample which is
output by a decoder when it is fed with the frame, note that the
The dts of a frame is the timestamp of the first sample which is
output by a decoder when it is fed with the frame. Note that the
data output is not necessarily what is coded in the frame, but may
be data from previous frames
dts is calculated by using a decode_delay+1 sized buffer for each
be data from previous frames.
dts is calculated by using a decode_delay + 1 sized buffer for each
stream, into which the current pts is inserted and the element with
the smallest value is removed, this is then the current dts
this buffer is initialized with decode_delay -1 elements
the smallest value is removed. This is then the current dts.
This buffer is initialized with decode_delay - 1 elements.
Pts of all frames in all streams MUST be bigger or equal to dts of all
pts of all frames in all streams MUST be bigger or equal to dts of all
previous frames in all streams, compared in common timebase. (EOR
frames are NOT exempt from this rule)
Dts of all frames MUST be bigger or equal to dts of all previous frames
in the same stream
frames are NOT exempt from this rule.)
dts of all frames MUST be bigger or equal to dts of all previous frames
in the same stream.
width (v) / height (v)
width and height of the video in pixels
MUST be set to the coded width/height, MUST NOT be 0
Width and height of the video in pixels.
MUST be set to the coded width/height, MUST NOT be 0.
sample_width (v) /sample_height (v) (aspect ratio)
sample_width is the horizontal distance between samples
sample_width and sample_height MUST be relatively prime if not zero
both MUST be 0 if unknown otherwise both MUST be non zero
sample_width is the horizontal distance between samples.
sample_width and sample_height MUST be relatively prime if not zero.
Both MUST be 0 if unknown otherwise both MUST be nonzero.
colorspace_type (v)
0 unknown
@ -716,21 +714,21 @@ colorspace_type (v)
18 ITU Rec 709 Y range: 0..255 Cb/Cr range: 0..255
samplerate_num (v) / samplerate_denom (v) = samplerate
the number of samples per second, MUST NOT be 0
The number of samples per second, MUST NOT be 0.
crc32 checksum
Generator polynomial is 0x104C11DB7. Starting value is zero.
checksum (u(32))
crc32 checksum
checksum is calculated for the area pointed to by forward_ptr not
including the checksum itself (from first byte after the
The checksum is calculated for the area pointed to by forward_ptr
not including the checksum itself (from first byte after the
packet_header until last byte before the checksum).
for frame headers the checksum contains the framecode byte and all
following bytes up to the checksum itself
For frame headers the checksum contains the framecode byte and all
following bytes up to the checksum itself.
header_checksum (u(32))
checksum over the startcode and forward pointer
Checksum over the startcode and forward pointer.
Syncpoint tags:
---------------
@ -738,7 +736,7 @@ Syncpoint tags:
back_ptr_div16 (v)
back_ptr = back_ptr_div16 * 16 + 15
back_ptr must point to a position up to 15 bytes before a syncpoint
startcode. Relative to position of current syncpoint. The syncpoint
startcode, relative to position of current syncpoint. The syncpoint
pointed to MUST be the closest syncpoint such that at least one keyframe
with a pts lower or equal to the current syncpoint's global_key_pts for
all streams lies between it and the current syncpoint.
@ -756,23 +754,23 @@ Index tags:
-----------
max_pts (t)
The highest pts in the entire file
the highest pts in the entire file
syncpoints (v)
number of indexed syncpoints
syncpoint_pos_div16 (v)
offset from beginning of file to up to 15 bytes before the syncpoint
referred to in this index entry. Relative to position of last
The offset from the beginning of the file to up to 15 bytes before the
syncpoint referred to in this index entry. Relative to position of last
syncpoint.
has_keyframe
indicates whether this stream has a keyframe between this syncpoint and
Indicates whether this stream has a keyframe between this syncpoint and
the last syncpoint.
keyframe_pts
The pts of the first keyframe for this stream in the region between the
2 syncpoints, in the stream's timebase. (EOR frames are also keyframes)
2 syncpoints, in the stream's timebase. (EOR frames are also keyframes.)
eor_pts
Coded only if EOR is set at the position of the syncpoint. The pts of
@ -790,22 +788,23 @@ Info tags:
----------
stream_id_plus1 (v)
Stream this info packet applies to. If zero, packet applies to whole
file.
Stream this info packet applies to. If zero, packet applies to the
whole file.
chapter_id (s)
Id of chapter this packet applies to. If zero, packet applies to whole
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
The ID of the chapter this packet applies to. If zero, the packet applies
to the whole file. Positive chapter_id values represent real chapters and
MUST NOT overlap.
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.
chapter_id n MUST not be used unless there are at least n chapters in the
file
chapter_id n MUST NOT be used unless there are at least n chapters in the
file.
chapter_start (t)
timestamp of start of chapter
chapter_len (v)
Length of chapter in same timebase of chapter_start.
Length of chapter in the same timebase as chapter_start.
count (v)
number of name/value pairs in this info packet
@ -815,94 +814,95 @@ type
"v" -> unsigned integer
"s" -> signed integer
"r" -> rational
Note: nonstandard fields should be prefixed by "X-"
Note: MUST be less than 6 byte long (might be increased to 64 later)
Note: Nonstandard fields should be prefixed by "X-".
Note: MUST be less than 6 byte long (might be increased to 64 later).
info packet types
the name of the info entry, valid names are
The name of the info entry. Valid names are
"Author"
"Description"
"Copyright"
"Encoder"
the name & version of the software used for encoding
The name & version of the software used for encoding.
"Title"
"Cover" (allowed types are "PNG" and "JPEG")
image of the (CD, DVD, VHS, ..) cover (preferably PNG or JPEG)
"Source"
"DVD", "VCD", "CD", "MD", "FM radio", "VHS", "TV", "LD"
Optional: appended PAL, NTSC, SECAM, ... in parentheses
Optional: Appended PAL, NTSC, SECAM, ... in parentheses.
"SourceContainer"
"nut", "mkv", "mov", "avi", "ogg", "rm", "mpeg-ps", "mpeg-ts", "raw"
"SourceCodecTag"
the source codec id like a fourcc which was used to store a specific
stream in its SourceContainer
The source codec ID like a FourCC which was used to store a specific
stream in its SourceContainer.
"CaptureDevice"
"BT878", "BT848", "webcam", ... (more exact names are fine too)
"BT878", "BT848", "webcam", ... (or more precise names)
"CreationTime"
"2003-01-20 20:13:15Z", ...
(ISO 8601 format, see http://www.cl.cam.ac.uk/~mgk25/iso-time.html)
Note: do not forget the timezone
Note: Do not forget the timezone.
"Keywords"
"Language"
An ISO 639-2 (three-letter) language code, optionally followed by an
ISO 3166-1 country code that is separated from the language
code by a hyphen. All codes defined in ISO 639-2 are allowed,
including "und" (Undetermined), "mul" (Multiple languages)
see http://www.loc.gov/standards/iso639-2/
including "und" (Undetermined), "mul" (Multiple languages).
See http://www.loc.gov/standards/iso639-2/
and http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html
the language code
a demuxer MUST ignore unknown language and country codes instead of
treating them as an error
A demuxer MUST ignore unknown language and country codes instead of
treating them as an error.
"Disposition"
"original", "dub" (translated), "comment", "lyrics", "karaoke"
Note: if someone needs some others, please tell us about them, so we
can add them to the official standard (if they are sane)
Note: nonstandard fields should be prefixed by "X-"
Note: names of fields SHOULD be in English if a word with the same
meaning exists in English
Note: MUST be less than 64 bytes long
Note: If someone needs some others, please tell us about them, so we
can add them to the official standard (if they are sane).
Note: Nonstandard fields should be prefixed by "X-".
Note: Names of fields SHOULD be in English if a word with the same
meaning exists in English.
Note: MUST be less than 64 bytes long.
value
value of this name/type pair
stuffing
0x80 can be placed in front of any type v entry for stuffing purposes
except the forward_ptr and all fields in the frame header where a
maximum of 8 stuffing bytes per field are allowed
0x80 can be placed in front of any type v entry for stuffing purposes.
Exceptions are the forward_ptr and all fields in the frame header where
a maximum of 8 stuffing bytes per field are allowed.
Structure:
----------
the headers MUST be in exactly the following order (to simplify demuxer design)
The headers MUST be in exactly the following order (to simplify demuxer design).
main header
stream_header (id=0)
stream_header (id=1)
...
stream_header (id=n)
headers may be repeated, but if they are, then they MUST all be repeated
together and repeated headers MUST be identical
Headers may be repeated, but if they are, then they MUST all be repeated
together and repeated headers MUST be identical.
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.
Note: this allows an implementation reading the file to locate backup
headers in O(log filesize) time as opposed to O(filesize)
Note: This allows an implementation reading the file to locate backup
headers in O(log filesize) time as opposed to O(filesize).
headers MUST be placed at least at the start of the file and immediately before
the index or at the file end if there is no index
headers MUST be repeated at least twice (so they exist three times in a file)
Headers MUST be placed at least at the start of the file and immediately before
the index or at the end of the file if there is no index.
Headers MUST be repeated at least twice (so they exist three times in a file).
there MUST be a sync point immediately before the first frame after any headers
There MUST be a syncpoint immediately before the first frame after any headers.
Index:
------
Note: with realtime streaming, there is no end, so no index there either
Note: With realtime streaming, there is no end, so no index there either.
Index MAY only be repeated after main headers.
If an index is written anywhere in the file, it MUST be written at end of
file as well.
@ -911,55 +911,56 @@ file as well.
Info:
-----
If a info packet is stored anywhere then a muxer MUST also store an identical
info packet after every main-stream-header set
If an info packet is stored anywhere then a muxer MUST also store an identical
info packet after every main-stream-header set.
If a demuxer has seen several info packets with the same chapter_id and
stream_id then it MUST ignore all but the one with the highest position in
the file
the file.
demuxers SHOULD NOT search the whole file for info packets
Demuxers SHOULD NOT search the whole file for info packets.
demuxer (non-normative):
------------------------
in the absence of a valid header at the beginning, players SHOULD search for
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 (including a syncpoint) is
found.
Seeking without an index (non-normative):
-----------------------------------------
A. backward seeking
1. perform a binary search on the syncpoint timestamps finding the one
which is largest and <= the target timestamp
1. Perform a binary search on the syncpoint timestamps finding the one
which is largest and <= the target timestamp.
B. forward seeking
1a. perform a binary search on the syncpoint timestamps finding the one
which is smallest and >= the target timestamp
1b. perform a binary search on the syncpoint back pointers finding the
1a. Perform a binary search on the syncpoint timestamps finding the one
which is smallest and >= the target timestamp.
1b. Perform a binary search on the syncpoint back pointers finding the
smallest one which has a back ptr >= the position of what was found in 1.
2. follow the back pointer to the corresponding syncpoint
2. Follow the back pointer to the corresponding syncpoint.
Seeking with an index (non-normative):
--------------------------------------
The demuxer only has to find the appropriate keyframe in the index and
start demuxing from the previous syncpoint
start demuxing from the previous syncpoint.
Note, more complicated seeking methods exist which are capable of quickly
seeking to the optimal point in the presence of an index even if only a
subset of all streams is active
subset of all streams is active.
A muxer SHOULD place syncpoints so that that simple low complexity seeking
works with fine granularity, that is syncpoints should be placed prior
to keyframes instead of non keyframes and with high enough frequency
works with fine granularity. That is, syncpoints should be placed prior
to keyframes instead of non-keyframes and with high enough frequency
(once per second unless there are no keyframes between this and the previous
syncpoint)
syncpoint).
encoders SHOULD place keyframes so that the number of points where all
streams have a keyframe at the same time is maximized, this ensures that
Encoders SHOULD place keyframes so that the number of points where all
streams have a keyframe at the same time is maximized. This ensures that
seeking (complicated or not) does not need to demux and decode significant
amounts of data to reach a point where a presentable frame for each stream
is available after seeking
is available after seeking.
Semantic requirements:
@ -971,9 +972,9 @@ It often highly improves usability and is therefore strongly encouraged.
A demuxer MUST NOT demux a stream which contains more than one stream, or which
is wrapped in a structure to facilitate more than one stream or otherwise
duplicate the role of a container. any such file is to be considered invalid.
for example vorbis in ogg in nut is invalid, as is
mpegvideo+mpegaudio in mpeg-ps/ts in nut or dvvideo + dvaudio in dv in nut
duplicate the role of a container. Any such file is to be considered invalid.
For example Vorbis in Ogg in NUT is invalid, as is
mpegvideo + mpegaudio in MPEG-PS/TS in NUT or dvvideo + dvaudio in DV in NUT.
@ -1029,7 +1030,7 @@ static inline int put_v(BufferContext *bc, uint64_t val){
if(space_left(bc) < 9) return -1;
val &= 0x7FFFFFFFFFFFFFFFULL; // FIXME can only encode up to 63 bits currently
val &= 0x7FFFFFFFFFFFFFFFULL; // FIXME: Can only encode up to 63 bits ATM.
for(i=7; ; i+=7){
if(val>>i == 0) break;
}