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">
On Sun, Oct 28, 2007 at 02:34:36AM +0200, lu_zero wrote:
Author: lu_zero Date: Sun Oct 28 02:34:35 2007 New Revision: 507
Log: yet another update
this is not a acceptable svn log message
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.
huh? a frame is part of a (video) frame ?
</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>
this is unclear if not outright wrong it makes it look as if only index and info packets may be repeated also the "may" is not correct headers at least have strict repeation rules [...]
+ <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.
i dont think this is an english sentence
+ 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>
s/be able to deal with/ignore/ or something like that same for nut.txt if thats containing this as well [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle
On Sun, Oct 28, 2007 at 03:44:31AM +0100, Michael Niedermayer wrote:
On Sun, Oct 28, 2007 at 02:34:36AM +0200, lu_zero wrote:
Author: lu_zero Date: Sun Oct 28 02:34:35 2007 New Revision: 507
Log: yet another update
this is not a acceptable svn log message
:)
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.
huh? a frame is part of a (video) frame ?
A frame is exactly one video frame. Less or more is not allowed.
- <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>
this is unclear if not outright wrong it makes it look as if only index and info packets may be repeated also the "may" is not correct headers at least have strict repeation rules
Agree. Rich
Rich Felker wrote:
A frame is exactly one video frame. Less or more is not allowed.
updating accordingly
- <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> this is unclear if not outright wrong it makes it look as if only index and info packets may be repeated also the "may" is not correct headers at least have strict repeation rules
Agree.
Please, either clarify the nut.txt or patch the draft. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Michael Niedermayer wrote:
On Sun, Oct 28, 2007 at 02:34:36AM +0200, lu_zero wrote:
Author: lu_zero Date: Sun Oct 28 02:34:35 2007 New Revision: 507
Log: yet another update
this is not a acceptable svn log message
I'll update the message soon (was too tired to think something better probably)
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.
huh? a frame is part of a (video) frame ?
a nut frame can hold a slice?
</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>
this is unclear if not outright wrong it makes it look as if only index and info packets may be repeated also the "may" is not correct headers at least have strict repeation rules
check the definition of MAY. Repetition rules doesn't change the fact you can have 0,N copies of them. I agree it could be clarified.
[...]
+ <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.
i dont think this is an english sentence
I removed "followed by" but I didn't put "following fields:", my bad
+ 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>
s/be able to deal with/ignore/ or something like that same for nut.txt if thats containing this as well
cf. nut.txt: 171 Note: Demuxers MUST be able to deal with new and unknown headers. the nut.txt is unclear about that in the very same way. updating the commit message right now. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
participants (4)
-
lu_zero -
Luca Barbato -
Michael Niedermayer -
Rich Felker