Author: lu_zero
Date: Sun Oct 28 10:58:02 2007
New Revision: 511
Log:
Whitespace changes
Modified:
docs/draft-niedermayer-nut-00.xml
Modified: docs/draft-niedermayer-nut-00.xml
============================================================
==================
--- docs/draft-niedermayer-nut-00.xml (original)
+++ docs/draft-niedermayer-nut-00.xml Sun Oct 28 10:58:02
2007
 -1,356
+1,356
-<?xml version="1.0"
encoding="UTF-8"?>
-<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
-<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bib
xml/reference.RFC.2119.xml">
-]>
-<?rfc toc="yes"?>
-<?rfc symrefs="yes"?>
-<?rfc compact="yes"?>
-<?rfc subcompact="no"?>
-<?rfc strict="no"?>
-<?rfc rfcedstyle="yes"?>
-<rfc category="std" docName=""
- ipr="full3978">
- <front>
-
- <title abbrev="NUT Container
Format">NUT Multimedia Container File Format
- </title>
-
- <!-- see RFC2223 for guidelines regarding author
names -->
-
- <author fullname="Michael Niedermayer"
initials="M"
- surname="Niedermayer">
- <organization>FFmpeg</organization>
-
- <address>
- <email>michaelnigmx.at</email>
- </address>
- </author>
- <author fullname="Luca Barbato"
initials="L" role="editor"
- surname="Barbato">
- <organization>Politecnico di
Torino</organization>
-
- <address>
- <postal>
- <street>Corso Duca degli Abruzzi
25</street>
-
- <city>10135 Torino</city>
-
- <country>Italy</country>
- </postal>
-
- <email>lu_zerogentoo.org</email>
- </address>
- </author>
-
- <date year="2007" />
-
- <area>General</area>
-
-<!-- <workgroup>AVT Working
Group</workgroup> -->
-
- <keyword>Internet-Draft</keyword>
-
- <keyword>RTP</keyword>
-
- <keyword>SCTP</keyword>
-
- <abstract>
- <t>This memo defines a method for efficiently
storing generic multimedia
- streams so that operation like seeking and recover
for error can be
- performed with minimal computational cost. Minimal
overhead and maximal
- extensibility had been considered in the development
of the format.</t>
- </abstract>
-
- <note title="Editors Note">
- <t>All references to RFC XXXX are to be
replaced by references to the
- RFC number of this memo, when
published.</t>
- </note>
-
- </front>
-
- <middle>
- <section title="Introduction">
- <!-- It is good practice to echo the abstract in
the Introduction,
-providing citations here. -->
-
- <t>NUT is a 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.</t>
- <t>This document defines:
- <list style="hanging">
- <t> The file format layout
- </t>
- <t> The common stream interleaving rules
- </t>
-<!-- <t> A simple provision how to map nut
streams to rtp.
- </t> -->
- </list>
- </t>
-
- <section title="Terminology">
- <t>The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL",
"SHALL NOT",
- "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and
"OPTIONAL" in this
- document are to be interpreted as described in
<xref target="RFC2119" />.</t>
- <t> This document refers to the following
definitions
- <list style="hanging">
- <t hangText="pts"> Presentation
time of the first frame/sample that
- is completed by decoding the coded frame.
- </t>
- <t hangText="dts"> The time
when a frame is input into a
- synchronous 1-in-1-out decoder.
- </t>
- <t hangText="frame"> Minimal
unit of information that can be
- decoded, it is usually holds a video frame, a
group of
- audio samples or a subtitle line.
- </t>
- <t hangText="Keyframe"> A
keyframe is a frame from which you can
- start decoding.
- 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
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 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.
- </t>
- </list>
- </t>
- </section>
- <section title="Syntax Convetions">
- <t> Since NUT heavily uses variable length
fields, the simplest way to
- describe it is using a pseudocode approach instead
of graphical
- bitfield descriptions.
- </t>
- <t> The syntax uses datatypes, tagnames and
C-like constructs. </t>
-
- <section title="Datatypes">
-
- <t>
- <list style="hanging">
- <t hangText="f(n)"> n fixed
bits in bigendian order</t>
- <t hangText="u(n)"> Unsigned
value encoded in n bits MSB-first</t>
-
- <t hangText="v"> Unsigned
variable length value.
- <figure anchor="Variable Length
Unsigned Figure" title="Variable
- Length Unsigned Value">
- <artwork><![CDATA[
- value=0
- do{
- more_data u(1)
- data u(7)
- value= 128*value + data
- }while(more_data)]]>
- </artwork>
- </figure>
- Values can be encoded using the following logic:
the data is in
- network order, every byte has the most
significant bit used as
- flag and the following 7 used to store the
value.
- The first N bit are to be taken, where N is
number of bits
- representing the value modulo 7, and stored in
the first byte.
- If there are more bits, the flag bit is set to 1
and the subsequent
- 7bit are stored in the following byte, if there
are remaining bits
- set the flag to 1 and the same procedure is
repeated. <br />
- The ending byte has the flag bit set to 0.
- In order to decode it is enough to iterate over
the bytes until the
- flag bit set to 0, for every byte the data is
added to the
- accumulated value multiplied by 128.
- </t>
- <t hangText="s"> Signed
variable length value.
- <figure anchor="Variable Length
Signed Figure" title="Variable
- Length Signed Value">
- <artwork><![CDATA[
- temp v
- temp++
- if(temp&1) value= -(temp>>1)
- else value= (temp>>1)]]>
- </artwork>
- </figure>
- The signed values are encoded as the absolute
value multiplied by
- 2, positive numbers have 1 subtracted to the
value. [FIXME: why not
- just shift&sign]
- </t>
- <t hangText="vb"> Variable
length binary data (or utf-8 string).
- <figure anchor="Variable Length
String Figure" title="Variable
- Length Signed Value">
- <artwork><![CDATA[
- length v
- for(i=0; i<length; i++){
- data[i] u(8)
- }]]>
- </artwork>
- </figure>
- Strings and binary data can be encoded
basically writing the byte
- count as a Variable Length Unsigned Value and
the the string.
- The strings MUST be encoded in utf-8
- </t>
- <t hangText="t"> Universal
timestamp.
- <figure anchor="Universal
Timestamp" title="Variable
- Length Timestamp">
- <artwork><![CDATA[
- tmp v
- id= tmp % time_base_count
- value= (tmp / time_base_count) * time_base[id]]]>
- </artwork>
- </figure>
- [FIXME]
- </t>
- </list>
- </t>
-
- </section>
-
- </section>
- </section>
-
- <section title="NUT file layout">
-
- <t>Every NUT file starts with an identification
string, main (global)
- headers and per stream headers follow, frame data is
interleaved with
- syncpoint packets. Optional info packets and index
packet MAY be present,
- in multiple copies, in order to improve
resilience</t>
- <section title="Low level element
description">
- <section title="Startcodes">
- <t>Every startcode is a fixed 64bit value,
the MSB contains the value
- 'N', the following bytes contain a specific
string. There are 5 types
- of startcode, each of them is used as marker for
a specific NUT
- packet.</t>
- <t>
- <list style="hanging">
- <t
hangText="main_startcode">
- <figure anchor="main_startcode"
title="Main Startcode">
- <artwork><![CDATA[
- 0x7A561F5F04ADULL + (((uint64_t)('N'<<8) +
'M')<<48)
- ]]>
- </artwork>
- </figure>
- </t>
- <t
hangText="stream_startcode">
- <figure
anchor="stream_startcode" title="Stream
Startcode">
- <artwork><![CDATA[
- 0x11405BF2F9DBULL + (((uint64_t)('N'<<8) +
'S')<<48)
- ]]>
- </artwork>
- </figure>
- </t>
- <t
hangText="syncpoing_startcode">
- <figure
anchor="syncpoing_startcode" title="Syncpoint
Startcode">
- <artwork><![CDATA[
- 0xE4ADEECA4569ULL + (((uint64_t)('N'<<8) +
'K')<<48)
- ]]>
- </artwork>
- </figure>
- </t>
- <t
hangText="index_startcode">
- <figure anchor="index_startcode"
title="Index Startcode">
- <artwork><![CDATA[
- 0xDD672F23E64EULL + (((uint64_t)('N'<<8) +
'X')<<48)
- ]]>
- </artwork>
- </figure>
- </t>
- <t
hangText="info_startcode">
- <figure anchor="info_startcode"
title="Info Startcode">
- <artwork><![CDATA[
- 0xAB68B596BA78ULL + (((uint64_t)('N'<<8) +
'I')<<48)
- ]]>
- </artwork>
- </figure>
- </t>
- </list>
- </section>
- </section>
-
- <section title="High level File
structure">
- <t>The structure of an undamaged file SHOULD
consists in the following
- elements: file_id_string, the main header, the
stream headers,
- the optional info packets, the optional index,
frames intermixed with
- syncpoints.
- Demuxers SHOULD be flexible and be able to deal
with damaged headers so is RECOMMENDED to use a loop
able to adapt to corruptions and
- misordering, the file scheme in figure
<xref="file representation" />
- shows a possible parsing method. Demuxers MUST
ignore new
- and unknown headers.</t>
- <figure anchor="file representation"
title="File representation">
- <artwork><![CDATA[file:
- file_id_string
- while(!eof){
- if(next_byte == 'N'){
- packet_header
- switch(startcode){
- case main_startcode: main_header;
break;
- case stream_startcode:stream_header;
break;
- case info_startcode: info_packet;
break;
- case index_startcode: index;
break;
- case syncpoint_startcode: syncpoint;
break;
- }
- packet_footer
- }else
- frame
- }]]>
- </artwork>
- </figure>
- </section>
- <section title="Main Header">
- <t>[TODO]</t>
- </section>
- <section title="Reserved Headers">
- <t>[TODO]</t>
- </section>
- <section title="Stream Header">
- <t>[TODO]</t>
- </section>
- <section title="Info">
- <t>[TODO]</t>
- </section>
- <section title="Index">
- <t>[TODO]</t>
- </section>
- <section title="Syncpoint">
- <t>[TODO]</t>
- </section>
- </section>
-
- <section title="Interleaving Rules">
- </section>
-
- <section title="IANA Considerations">
- <t>[TODO] In order to comply with IESG policy
as set forth in
- http://www.ietf
.org/ID-Checklist.html, every Internet-Draft that is
- submitted to the IESG for publication MUST contain an
IANA
- Considerations section. </t>
-
- </section>
-
- <section title="Security
Considerations">
- <t>[TODO]</t>
- </section>
-
- <section title="Acknowledgements">
- <t>Thanks to Marshall Rose for developing the
XML2RFC format.</t>
-
- </section>
- </middle>
-
- <back>
-
- <references title="Normative
References">
-
- &rfc2119;
-
- <!-- <t>[TODO]: Add your own normative
references.</t>-->
- </references>
-
- <references title="Informative
References">
-
- <!-- <t>[TODO] Add your own informative
references</t>-->
- </references>
- </back>
-</rfc>
-<!-- vim: set sw=2 sts=2 et tw=79: -->
+<?xml version="1.0"
encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bib
xml/reference.RFC.2119.xml">
+]>
+<?rfc toc="yes"?>
+<?rfc symrefs="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<?rfc strict="no"?>
+<?rfc rfcedstyle="yes"?>
+<rfc category="std" docName=""
+ ipr="full3978">
+ <front>
+
+ <title abbrev="NUT Container
Format">NUT Multimedia Container File Format
+ </title>
+
+ <!-- see RFC2223 for guidelines regarding author
names -->
+
+ <author fullname="Michael Niedermayer"
initials="M"
+ surname="Niedermayer">
+ <organization>FFmpeg</organization>
+
+ <address>
+ <email>michaelnigmx.at</email>
+ </address>
+ </author>
+ <author fullname="Luca Barbato"
initials="L" role="editor"
+ surname="Barbato">
+ <organization>Politecnico di
Torino</organization>
+
+ <address>
+ <postal>
+ <street>Corso Duca degli Abruzzi
25</street>
+
+ <city>10135 Torino</city>
+
+ <country>Italy</country>
+ </postal>
+
+ <email>lu_zerogentoo.org</email>
+ </address>
+ </author>
+
+ <date year="2007" />
+
+ <area>General</area>
+
+<!-- <workgroup>AVT Working
Group</workgroup> -->
+
+ <keyword>Internet-Draft</keyword>
+
+ <keyword>RTP</keyword>
+
+ <keyword>SCTP</keyword>
+
+ <abstract>
+ <t>This memo defines a method for efficiently
storing generic multimedia
+ streams so that operation like seeking and recover
for error can be
+ performed with minimal computational cost. Minimal
overhead and maximal
+ extensibility had been considered in the development
of the format.</t>
+ </abstract>
+
+ <note title="Editors Note">
+ <t>All references to RFC XXXX are to be
replaced by references to the
+ RFC number of this memo, when
published.</t>
+ </note>
+
+ </front>
+
+ <middle>
+ <section title="Introduction">
+ <!-- It is good practice to echo the abstract in
the Introduction,
+ providing citations here. -->
+
+ <t>NUT is a 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.</t>
+ <t>This document defines:
+ <list style="hanging">
+ <t> The file format layout
+ </t>
+ <t> The common stream interleaving rules
+ </t>
+<!-- <t> A simple provision how to map nut
streams to rtp.
+ </t> -->
+ </list>
+ </t>
+
+ <section title="Terminology">
+ <t>The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL",
"SHALL NOT",
+ "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and
"OPTIONAL" in this
+ document are to be interpreted as described in
<xref target="RFC2119" />.</t>
+ <t> This document refers to the following
definitions
+ <list style="hanging">
+ <t hangText="pts"> Presentation
time of the first frame/sample that
+ is completed by decoding the coded frame.
+ </t>
+ <t hangText="dts"> The time
when a frame is input into a
+ synchronous 1-in-1-out decoder.
+ </t>
+ <t hangText="frame"> Minimal
unit of information that can be
+ decoded, it is usually holds a video frame, a
group of
+ audio samples or a subtitle line.
+ </t>
+ <t hangText="Keyframe"> A
keyframe is a frame from which you can
+ start decoding.
+ 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
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 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.
+ </t>
+ </list>
+ </t>
+ </section>
+ <section title="Syntax Convetions">
+ <t> Since NUT heavily uses variable length
fields, the simplest way to
+ describe it is using a pseudocode approach instead
of graphical
+ bitfield descriptions.
+ </t>
+ <t> The syntax uses datatypes, tagnames and
C-like constructs. </t>
+
+ <section title="Datatypes">
+
+ <t>
+ <list style="hanging">
+ <t hangText="f(n)"> n fixed
bits in bigendian order</t>
+ <t hangText="u(n)"> Unsigned
value encoded in n bits MSB-first</t>
+
+ <t hangText="v"> Unsigned
variable length value.
+ <figure anchor="Variable Length
Unsigned Figure" title="Variable
+ Length Unsigned Value">
+ <artwork><![CDATA[
+ value=0
+ do{
+ more_data u(1)
+ data u(7)
+ value= 128*value + data
+ }while(more_data)]]>
+ </artwork>
+ </figure>
+ Values can be encoded using the following logic:
the data is in
+ network order, every byte has the most
significant bit used as
+ flag and the following 7 used to store the
value.
+ The first N bit are to be taken, where N is
number of bits
+ representing the value modulo 7, and stored in
the first byte.
+ If there are more bits, the flag bit is set to 1
and the subsequent
+ 7bit are stored in the following byte, if there
are remaining bits
+ set the flag to 1 and the same procedure is
repeated. <br />
+ The ending byte has the flag bit set to 0.
+ In order to decode it is enough to iterate over
the bytes until the
+ flag bit set to 0, for every byte the data is
added to the
+ accumulated value multiplied by 128.
+ </t>
+ <t hangText="s"> Signed
variable length value.
+ <figure anchor="Variable Length
Signed Figure" title="Variable
+ Length Signed Value">
+ <artwork><![CDATA[
+ temp v
+ temp++
+ if(temp&1) value= -(temp>>1)
+ else value= (temp>>1)]]>
+ </artwork>
+ </figure>
+ The signed values are encoded as the absolute
value multiplied by
+ 2, positive numbers have 1 subtracted to the
value. [FIXME: why not
+ just shift&sign]
+ </t>
+ <t hangText="vb"> Variable
length binary data (or utf-8 string).
+ <figure anchor="Variable Length
String Figure" title="Variable
+ Length Signed Value">
+ <artwork><![CDATA[
+ length v
+ for(i=0; i<length; i++){
+ data[i] u(8)
+ }]]>
+ </artwork>
+ </figure>
+ Strings and binary data can be encoded
basically writing the byte
+ count as a Variable Length Unsigned Value and
the the string.
+ The strings MUST be encoded in utf-8
+ </t>
+ <t hangText="t"> Universal
timestamp.
+ <figure anchor="Universal
Timestamp" title="Variable
+ Length Timestamp">
+ <artwork><![CDATA[
+ tmp v
+ id= tmp % time_base_count
+ value= (tmp / time_base_count) * time_base[id]]]>
+ </artwork>
+ </figure>
+ [FIXME]
+ </t>
+ </list>
+ </t>
+
+ </section>
+
+ </section>
+ </section>
+
+ <section title="NUT file layout">
+
+ <t>Every NUT file starts with an identification
string, main (global)
+ headers and per stream headers follow, frame data is
interleaved with
+ syncpoint packets. Optional info packets and index
packet MAY be present,
+ in multiple copies, in order to improve
resilience</t>
+ <section title="Low level element
description">
+ <section title="Startcodes">
+ <t>Every startcode is a fixed 64bit value,
the MSB contains the value
+ 'N', the following bytes contain a specific
string. There are 5 types
+ of startcode, each of them is used as marker for
a specific NUT
+ packet.</t>
+ <t>
+ <list style="hanging">
+ <t
hangText="main_startcode">
+ <figure anchor="main_startcode"
title="Main Startcode">
+ <artwork><![CDATA[
+ 0x7A561F5F04ADULL + (((uint64_t)('N'<<8) +
'M')<<48)
+ ]]>
+ </artwork>
+ </figure>
+ </t>
+ <t
hangText="stream_startcode">
+ <figure
anchor="stream_startcode" title="Stream
Startcode">
+ <artwork><![CDATA[
+ 0x11405BF2F9DBULL + (((uint64_t)('N'<<8) +
'S')<<48)
+ ]]>
+ </artwork>
+ </figure>
+ </t>
+ <t
hangText="syncpoing_startcode">
+ <figure
anchor="syncpoing_startcode" title="Syncpoint
Startcode">
+ <artwork><![CDATA[
+ 0xE4ADEECA4569ULL + (((uint64_t)('N'<<8) +
'K')<<48)
+ ]]>
+ </artwork>
+ </figure>
+ </t>
+ <t
hangText="index_startcode">
+ <figure anchor="index_startcode"
title="Index Startcode">
+ <artwork><![CDATA[
+ 0xDD672F23E64EULL + (((uint64_t)('N'<<8) +
'X')<<48)
+ ]]>
+ </artwork>
+ </figure>
+ </t>
+ <t
hangText="info_startcode">
+ <figure anchor="info_startcode"
title="Info Startcode">
+ <artwork><![CDATA[
+ 0xAB68B596BA78ULL + (((uint64_t)('N'<<8) +
'I')<<48)
+ ]]>
+ </artwork>
+ </figure>
+ </t>
+ </list>
+ </section>
+ </section>
+
+ <section title="High level File
structure">
+ <t>The structure of an undamaged file SHOULD
consists in the following
+ elements: file_id_string, the main header, the
stream headers,
+ the optional info packets, the optional index,
frames intermixed with
+ syncpoints.
+ Demuxers SHOULD be flexible and be able to deal
with damaged headers so is RECOMMENDED to use a loop
able to adapt to corruptions and
+ misordering, the file scheme in figure
<xref="file representation" />
+ shows a possible parsing method. Demuxers MUST
ignore new
+ and unknown headers.</t>
+ <figure anchor="file representation"
title="File representation">
+ <artwork><![CDATA[file:
+ file_id_string
+ while(!eof){
+ if(next_byte == 'N'){
+ packet_header
+ switch(startcode){
+ case main_startcode: main_header;
break;
+ case stream_startcode:stream_header;
break;
+ case info_startcode: info_packet;
break;
+ case index_startcode: index;
break;
+ case syncpoint_startcode: syncpoint;
break;
+ }
+ packet_footer
+ }else
+ frame
+ }]]>
+ </artwork>
+ </figure>
+ </section>
+ <section title="Main Header">
+ <t>[TODO]</t>
+ </section>
+ <section title="Reserved Headers">
+ <t>[TODO]</t>
+ </section>
+ <section title="Stream Header">
+ <t>[TODO]</t>
+ </section>
+ <section title="Info">
+ <t>[TODO]</t>
+ </section>
+ <section title="Index">
+ <t>[TODO]</t>
+ </section>
+ <section title="Syncpoint">
+ <t>[TODO]</t>
+ </section>
+ </section>
+
+ <section title="Interleaving Rules">
+ </section>
+
+ <section title="IANA Considerations">
+ <t>[TODO] In order to comply with IESG policy
as set forth in
+ http://www.ietf
.org/ID-Checklist.html, every Internet-Draft that is
+ submitted to the IESG for publication MUST contain an
IANA
+ Considerations section. </t>
+
+ </section>
+
+ <section title="Security
Considerations">
+ <t>[TODO]</t>
+ </section>
+
+ <section title="Acknowledgements">
+ <t>Thanks to Marshall Rose for developing the
XML2RFC format.</t>
+
+ </section>
+ </middle>
+
+ <back>
+
+ <references title="Normative
References">
+
+ &rfc2119;
+
+ <!-- <t>[TODO]: Add your own normative
references.</t>-->
+ </references>
+
+ <references title="Informative
References">
+
+ <!-- <t>[TODO] Add your own informative
references</t>-->
+ </references>
+ </back>
+</rfc>
+<!-- vim: set sw=2 sts=2 et tw=79: -->
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
