- NUT-devel - lists.mplayerhq.hu

[nut]: r514 - docs/draft-niedermayer-nut-00.xml
by lu_zero 31 Dec '07

31 Dec '07

Author: lu_zero Date: Mon Dec 31 12:42:09 2007 New Revision: 514 Log: Import Bitstream syntax section from the informal spec 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 Mon Dec 31 12:42:09 2007 @@ -124,7 +124,7 @@ </list> </t> </section> - <section title="Syntax Convetions"> + <section title="Syntax Conventions"> <t> Since NUT heavily uses variable length fields, the simplest way to describe it is using a pseudocode approach instead of graphical bitfield descriptions. @@ -222,7 +222,6 @@ '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"> @@ -267,28 +266,28 @@ </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" /> + misordering, the file scheme in figure <xref target="file layout" /> shows a possible parsing method. Demuxers MUST ignore new - and unknown headers.</t> - <figure anchor="file representation" title="File representation"> + and unknown headers, considering them as "reserved".</t> + <figure anchor="file layout" title="File layout structure"> <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; + 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; + case unknown_startcode:reserved_headers; break; } packet_footer }else @@ -296,24 +295,229 @@ }]]> </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 title="Common Elements"> + <t>Each element in nut starts with a packet_header [FIXME explain why + and detail a bit], and end with a packet_footer.</t> + </section> + <section title="Main Header"> + <t>The main header [FIXME describe]</t> + <figure anchor="main_header" title="Main header structure"> + <artwork><![CDATA[main_header: + version v + stream_count v + max_distance v + time_base_count v + for(i=0; i<time_base_count; i++) + time_base_num v + time_base_denom v + time_base[i]= time_base_num/time_base_denom + tmp_pts=0 + tmp_mul=1 + tmp_stream=0 + for(i=0; i<256; ){ + tmp_flag v + tmp_fields v + if(tmp_fields>0) tmp_pts s + if(tmp_fields>1) tmp_mul v + if(tmp_fields>2) tmp_stream v + if(tmp_fields>3) tmp_size v + else tmp_size=0 + if(tmp_fields>4) tmp_res v + else tmp_res=0 + if(tmp_fields>5) count v + else count= tmp_mul - tmp_size + for(j=6; j<tmp_fields; j++){ + tmp_reserved[i] v + } + for(j=0; j<count && i<256; j++, i++){ + if (i == 'N') { + flags[i]= FLAG_INVALID; + j--; + continue; + } + flags[i]= tmp_flag; + stream_id[i]= tmp_stream; + data_size_mul[i]= tmp_mul; + data_size_lsb[i]= tmp_size + j; + pts_delta[i]= tmp_pts; + reserved_count[i]= tmp_res; + } + } + reserved_bytes]]> + </artwork> + </figure> + </section> + <section title="Reserved Headers"> + <t>Any element with an unknown startcode is considered reserved and + MUST be ignored.</t> + <figure anchor="reserved header" title="Reserved header structure"> + <artwork><![CDATA[reserved_headers + while(next_byte == 'N' && next_code != main_startcode + && next_code != stream_startcode + && next_code != info_startcode + && next_code != index_startcode + && next_code != syncpoint_startcode){ + packet_header + reserved_bytes + packet_footer + }]]> + </artwork> + </figure> + </section> + <section title="Stream Header"> + <t>[TODO]</t> + <figure anchor="stream header" title="Stream header structure"> + <artwork><![CDATA[stream_header: + stream_id v + stream_class v + fourcc vb + time_base_id v + msb_pts_shift v + max_pts_distance v + decode_delay v + stream_flags v + codec_specific_data vb + if(stream_class == video){ + width v + height v + sample_width v + sample_height v + colorspace_type v + }else if(stream_class == audio){ + samplerate_num v + samplerate_denom v + channel_count v + } + reserved_bytes]]> + </artwork> + </figure> + </section> + <section title="Basic Packets"> + <section title="Frame"> + <t>[TODO]</t> + <figure anchor="frame structure" title="Frame structure"> + <artwork><![CDATA[frame: + frame_code f(8) + frame_flags= flags[frame_code] + frame_res= reserved_count[frame_code] + if(frame_flags&FLAG_CODED){ + coded_flags v + frame_flags ^= coded_flags + } + if(frame_flags&FLAG_STREAM_ID){ + stream_id v + } + if(frame_flags&FLAG_CODED_PTS){ + coded_pts v + } + if(frame_flags&FLAG_SIZE_MSB){ + data_size_msb v + } + if(frame_flags&FLAG_RESERVED) + frame_res v + for(i=0; i<frame_res; i++) + reserved v + if(frame_flags&FLAG_CHECKSUM){ + checksum u(32) + } + data]]> + </artwork> + </figure> + </section> + <section title="Info"> + <t>[TODO]</t> + <figure anchor="info structure" title="Info structure"> + <artwork><![CDATA[info_packet: + stream_id_plus1 v + chapter_id s (Note: Due to a typo this was v + until 2006-11-04.) + chapter_start t + chapter_len v + count v + for(i=0; i<count; i++){ + name vb + value s + if (value==-1){ + type= "UTF-8" + value vb + }else if (value==-2){ + type vb + value vb + }else if (value==-3){ + type= "s" + value s + }else if (value==-4){ + type= "t" + value t + }else if (value<-4){ + type= "r" + value.den= -value-4 + value.num s + }else{ + type= "v" + } + } + reserved_bytes]]> + </artwork> + </figure> + </section> + <section title="Index"> + <t>[TODO]</t> + <figure anchor="index structure" title="Index structure"> + <artwork><![CDATA[index: + max_pts t + syncpoints v + for(i=0; i<syncpoints; i++){ + syncpoint_pos_div16 v + } + for(i=0; i<stream_count; i++){ + last_pts= -1 + for(j=0; j<syncpoints; ){ + x v + type= x & 1 + x>>=1 + n=j + if(type){ + flag= x & 1 + x>>=1 + while(x--) + has_keyframe[n++][i]=flag + has_keyframe[n++][i]=!flag; + }else{ + while(x != 1){ + has_keyframe[n++][i]=x&1; + x>>=1; + } + } + for(; j<n && j<syncpoints; j++){ + if (!has_keyframe[j][i]) continue + A v + if(!A){ + A v + B v + eor_pts[j][i] = last_pts + A + B + }else + B=0 + keyframe_pts[j][i] = last_pts + A + last_pts += A + B + } + } + } + reserved_bytes + index_ptr u(64)]]> + </artwork> + </figure> + </section> + <section title="Syncpoint"> + <t>[TODO]</t> + <figure anchor="syncpoint structure" title="Syncpoint structure"> + <artwork><![CDATA[syncpoint: + global_key_pts t + back_ptr_div16 v + reserved_bytes]]> + </artwork> + </figure> </section> + </section> </section> </section>

2 1

[nut]: r513 - docs/draft-niedermayer-nut-00.xml
by lu_zero 31 Dec '07

31 Dec '07

Author: lu_zero Date: Mon Dec 31 12:42:06 2007 New Revision: 513 Log: Copying conditions (as suggested by Debian) 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 Mon Dec 31 12:42:06 2007 @@ -331,7 +331,13 @@ <section title="Security Considerations"> <t>[TODO]</t> </section> - + <section title="Copying Conditions"> + <t>The authors agree to grant third parties the irrevocable right to + copy, use and distribute the work, with or without modification, in + any medium, without royalty, provided that, unless separate permission + is granted, redistributed modified works do not contain misleading + author, version, name of work, or endorsement information.</t> + </section> <section title="Acknowledgements"> <t>Thanks to Marshall Rose for developing the XML2RFC format.</t>

1 0

rfc drafting
by Rich Felker 20 Nov '07

20 Nov '07

hi all, lu wants me to help on drafting and formatting the rfc, and i think this is a good thing. so i started looking at it and have some ideas for changes to make, but i don't want to step on any feet.. abstract: this should mention the codec-agnosticism and ability to perform container-level operations without any awareness of the data format, since these aspects are probably the most novel from a multimedia standards perspective. i want to add the text "without regard for the specific formats of the streams, and" before "with minimal computational cost" and perhaps work more on improving the content of the abstract. definitions: the definition of pts is somewhat confusing in relation to b frames and out of order decoding. can we do something about "completed by decoding the coded frame" to make it more clear? the definition of dts is rather vague... frame: i had a good formal definition the other day but can't remember at the moment... keyframe: rewording for clarity and formal english: A keyframe is a frame in a stream at which decoding of that stream can successfully begin independent of prior frames. Keyframe status of frames within one stream is independent of any other streams. Assign to each frame in a stream an integer position n. The nth frame of a stream is a keyframe if and only if the mth frame, for each m≥n+k, can be decoded successfully without reference to data contained in the lth frame for any l<n, where k is the smallest nonnegative integer such that keyframes other than the initial frame can exist in the stream's coding scheme. This definition coincides with the ordinary notion of a keyframe for common video coding schemes where k=0, and also allows for overlapped-window audio coding schemes where k≥1 accounts for the missing overlap from the previous frame. Readers should be aware that this definition of keyframe is dependent on the ordering of frames according to pts and dts as mandated by this standard. data types: strings: the requirement that strings not contain U+0000 is mysteriously missing. also, i would like to change the terminology from "string" to "text" to align mostly with the posix sense of text (i.e. bytes must represent characters and must not contain 0). string is somewhat less precise imo because to some people binary data (or binary data without embedded 0's) is a "string" but not "text". also then we could move the requirements of text to a "definition of text" under the definitions section, which i think would be nice organizationally speaking. finally, lu thought this was okay but i'd like to run it by others: can i commit changes like these directly to the rfc xml file? the intent would not be to impose my wishes on others, but rather to accelerate completion of the document. i would certainly welcome others to revert or heavily alter anything objectionable and start discussions on the list as appropriate, but i feel now that we're to the stage of documenting the format we already designed rather than designing it, the types of potential objections are very different and much less severe and we always have the authoritative nut.txt to go back to. if anyone else has differing or better ideas on how to work on the rfc i'd be happy to hear them too. rich

4 12

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