October 2007 - NUT-devel - lists.mplayerhq.hu

Blast your ad to millions of blogs
by BlogBlaster＠natsuki.mplayerhq.hu 29 Oct '07

29 Oct '07

How would you like 2 Million Sites linking to your ad ? Weblog or blog population is exploding around the world, resembling the growth of e-mail users in the 1990s. Post your ads where people read them! - What if you could place your ad on all these sites ? Right, that would mean you would have millions of sites linking to your ad. http://www.promote-bz.net/blogblaster/ Unsubscribe http://www.promote-bz.net/remove/

1 0

[nut]: r512 - docs/draft-niedermayer-nut-00.xml
by lu_zero 28 Oct '07

28 Oct '07

Author: lu_zero Date: Sun Oct 28 16:28:21 2007 New Revision: 512 Log: slightly less broken grammar 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 16:28:21 2007 @@ -101,8 +101,8 @@ 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. + decoded, e.g. 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.

2 1

[nut]: r508 - docs/draft-niedermayer-nut-00.xml
by lu_zero 28 Oct '07

28 Oct '07

Author: lu_zero Date: Sun Oct 28 10:23:49 2007 New Revision: 508 Log: only full video frames allowed 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:23:49 2007 @@ -101,7 +101,7 @@ providing citations here. --> synchronous 1-in-1-out decoder. </t> <t hangText="frame"> Minimal unit of information that can be - decoded, it is usually holds a part of video frame, a group of + 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

3 2

[nut]: r507 - docs/draft-niedermayer-nut-00.xml
by lu_zero 28 Oct '07

28 Oct '07

Author: lu_zero Date: Sun Oct 28 02:34:35 2007 New Revision: 507 Log: yet another update 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 02:34:35 2007 @@ -101,8 +101,8 @@ providing citations here. --> synchronous 1-in-1-out decoder. </t> <t hangText="frame"> Minimal unit of information that can be - decoded completely, it is usually holds a full frame video frame, - a group of audio samples or a subtitle line. + decoded, it is usually holds a part of 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. @@ -212,10 +212,89 @@ providing citations here. --> <section title="NUT file layout"> - <t></t> - + <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>[TODO]</t> + <t>The structure of an undamaged file SHOULD consist in the + 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 be able to deal with 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> @@ -226,7 +305,7 @@ providing citations here. --> <section title="Stream Header"> <t>[TODO]</t> </section> - <section title="Info Packet"> + <section title="Info"> <t>[TODO]</t> </section> <section title="Index">

4 5

[nut]: r511 - docs/draft-niedermayer-nut-00.xml
by lu_zero 28 Oct '07

28 Oct '07

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/bibxml/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> - -  - - <author fullname="Michael Niedermayer" initials="M" - surname="Niedermayer"> - <organization>FFmpeg</organization> - - <address> - <email>michaelni(a)gmx.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_zero(a)gentoo.org</email> - </address> - </author> - - <date year="2007" /> - - <area>General</area> - - - - <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"> -  - - <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> - - </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; - -  - </references> - - <references title="Informative References"> - -  - </references> - </back> -</rfc> - +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ +<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/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> + +  + + <author fullname="Michael Niedermayer" initials="M" + surname="Niedermayer"> + <organization>FFmpeg</organization> + + <address> + <email>michaelni(a)gmx.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_zero(a)gentoo.org</email> + </address> + </author> + + <date year="2007" /> + + <area>General</area> + + + + <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"> +  + + <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> + + </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; + +  + </references> + + <references title="Informative References"> + +  + </references> + </back> +</rfc> +

1 0

[nut]: r510 - in docs: draft-niedermayer-nut-00.xml nut.txt
by lu_zero 28 Oct '07

28 Oct '07

Author: lu_zero Date: Sun Oct 28 10:23:53 2007 New Revision: 510 Log: Clarify the behaviour in case of unknown headers: ignoring them Modified: docs/draft-niedermayer-nut-00.xml docs/nut.txt Modified: docs/draft-niedermayer-nut-00.xml ============================================================================== --- docs/draft-niedermayer-nut-00.xml (original) +++ docs/draft-niedermayer-nut-00.xml Sun Oct 28 10:23:53 2007 @@ -275,7 +275,7 @@ providing citations here. --> 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 be able to deal with new + shows a possible parsing method. Demuxers MUST ignore new and unknown headers.</t> <figure anchor="file representation" title="File representation"> <artwork><![CDATA[file: Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Sun Oct 28 10:23:53 2007 @@ -168,7 +168,7 @@ file: 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. +Note: Demuxers MUST ignore new and unknown headers. file: file_id_string

1 0

[nut]: r509 - docs/draft-niedermayer-nut-00.xml
by lu_zero 28 Oct '07

28 Oct '07

Author: lu_zero Date: Sun Oct 28 10:23:51 2007 New Revision: 509 Log: rephrase the high level file description a bit 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:23:51 2007 @@ -269,9 +269,10 @@ providing citations here. --> </section> <section title="High level File structure"> - <t>The structure of an undamaged file SHOULD consist in the - file_id_string, the main header, the stream headers, the optional - info packets, the optional index, frames intermixed with syncpoints. + <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 be able to deal with new

1 0

[nut] [propchange]: r507 - svn:log
by lu_zero 28 Oct '07

28 Oct '07

Author: lu_zero Revision: 507 Property Name: svn:log Action: modified Property diff: --- old property value +++ new property value @@ -1 +1 @@ -yet another update \ No newline at end of file +first part of NUT file layout added.

1 0