- NUT-devel - lists.mplayerhq.hu

r20647 - trunk/DOCS/tech/nut.txt
by michael 03 Nov '06

03 Nov '06

Author: michael Date: Fri Nov 3 22:13:50 2006 New Revision: 20647 Modified: trunk/DOCS/tech/nut.txt Log: 2nd try for a keyframe definition based on richs comment Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Fri Nov 3 22:13:50 2006 @@ -42,11 +42,15 @@ SHOULD it is recommended to be done that way, but not strictly required keyframe - a frame which can be decoded correctly on its own (=without using - information from any other frames) - if no such frames exist in a codec (for example due to use of overlapped - transforms like the MDCT in an audio codec) then a keyframe shall be any - frame from which onward all frames can be decoded correctly + 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 storeage + order (that are all frames with a dts < frame[n].dts) + if no such frames exist (for example due to use of overlapped transforms + like the MDCT in an audio codec) then the definition shall be extended + by droping n out of the set of frames which must be decodable, if this + is still insufficient then n+1 shall be droped, and so on until there is + a keyframe (FIXME maybe move somewhere else?)

1 0

NUT spec and Keyframes
by Charles Iliya Krempeaux 03 Nov '06

03 Nov '06

Hello, I know most people who read the spec will know what keyframes are... but I'd suggest defining it in the spec too. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/

3 2

r20635 - trunk/DOCS/tech/nut.txt
by michael 03 Nov '06

03 Nov '06

Author: michael Date: Fri Nov 3 14:53:29 2006 New Revision: 20635 Modified: trunk/DOCS/tech/nut.txt Log: main header typo Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Fri Nov 3 14:53:29 2006 @@ -198,7 +198,7 @@ Headers: -main header: +main_header: version v stream_count v max_distance v

1 0

NUT Magic?
by Charles Iliya Krempeaux 03 Nov '06

03 Nov '06

Hello, I was looking over the NUT spec, and I just wanted to check about something. Does a NUT file have a "magic". (A special code at the beginning that marks it as being a NUT file?) >From the spec, I get the impression it doesn't, but that it starts off with a "version"? See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/

3 3

r20634 - trunk/DOCS/tech/nut.txt
by michael 03 Nov '06

03 Nov '06

Author: michael Date: Fri Nov 3 14:52:12 2006 New Revision: 20634 Modified: trunk/DOCS/tech/nut.txt Log: move file up so its found first, this probably improves readability Modified: trunk/DOCS/tech/nut.txt ============================================================================== --- trunk/DOCS/tech/nut.txt (original) +++ trunk/DOCS/tech/nut.txt Fri Nov 3 14:52:12 2006 @@ -116,6 +116,54 @@ Bitstream syntax: ================= +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 + } + +the structure of a 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 its simpler) +note, demuxers MUST be able to deal with new and unknown headers + +file: + file_id_string + while(!eof){ + packet_header, main_header, packet_footer + reserved_headers + for(i=0; i<stream_count; i++){ + packet_header, stream_header, packet_footer + reserved_headers + } + while(next_code == info_startcode){ + packet_header, info_packet, packet_footer + reserved_headers + } + if(next_code == index_startcode){ + packet_header, index_packet, packet_footer + } + if (!eof) while(next_code != main_startcode){ + if(next_code == syncpoint_startcode){ + packet_header, syncpoint, packet_footer + } + frame + reserved_headers + } + } + + Common elements: ---------------- @@ -319,53 +367,6 @@ Complete definition: -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 - } - -the structure of a 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 its simpler) -note, demuxers MUST be able to deal with new and unknown headers - -file: - file_id_string - while(!eof){ - packet_header, main_header, packet_footer - reserved_headers - for(i=0; i<stream_count; i++){ - packet_header, stream_header, packet_footer - reserved_headers - } - while(next_code == info_startcode){ - packet_header, info_packet, packet_footer - reserved_headers - } - if(next_code == index_startcode){ - packet_header, index_packet, packet_footer - } - if (!eof) while(next_code != main_startcode){ - if(next_code == syncpoint_startcode){ - packet_header, syncpoint, packet_footer - } - frame - reserved_headers - } - } - Tag description: ----------------

1 0

Typo in NUT Spec
by Charles Iliya Krempeaux 03 Nov '06

03 Nov '06

Hello, Found a typo in the spec. Where the main_header is defined, it is written as "main header:"... without a underscore like in other places in the spec. Should be "main_header:". See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/

2 1

www.nut.hu
by Charles Iliya Krempeaux 02 Nov '06

02 Nov '06

Hello, Did you guys know that www.nut.hu has been down? See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/

1 0

Sample NUT files?
by Charles Iliya Krempeaux 02 Nov '06

02 Nov '06

Hello, Are there any sample NUT files anywhere? See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/

1 0

[nut]: r173 - trunk/docs/nut-english.txt
by ods15 31 Oct '06

31 Oct '06

Author: ods15 Date: Tue Oct 31 16:58:40 2006 New Revision: 173 Modified: trunk/docs/nut-english.txt Log: add EOR Modified: trunk/docs/nut-english.txt ============================================================================== --- trunk/docs/nut-english.txt (original) +++ trunk/docs/nut-english.txt Tue Oct 31 16:58:40 2006 @@ -255,6 +255,17 @@ syncpoint is 16 bytes: 8 startcode + 1 forward_ptr + 1 timestamp + 1 back_ptr + 4 checksum + 1 frame_code +End of Relevance +EOR is a flag that can be attributed to a frame in any stream, and marks +the end of relavence of a stream on presentation, such as a subtitle +stream currently showing no subtitles on screen. EOR flag can only be +given to zero byte frames, and must be set as keyframe as well. Once EOR +is seen on such a stream, the stream is set EOR until the next keyframe on +that stream. Streams which are set EOR are ignored by back_ptr in +syncpoints until EOR is unset. The significance of EOR is to set the +stream as irrelevant when seeking and searching for optimal keyframes to +begin demuxing. + Error Checking There are several ways to detect a damaged stream in NUT during demuxing:

1 0

Call for volunteers to write NUT de/muxer for libavformat
by Oded Shimon 30 Oct '06

30 Oct '06

Subject pretty much says it all. A NUT de/muxer in libavformat is currently the major bottleneck for starting to advertise NUT. There are still complaints on the readability of the spec. Rich and I have been working on an informative "introduction" document which IMO gives the starting knowledge necessary to understand the spec. I might be completely wrong on this, but we cannot know until someone who has no previous knowledge on NUT steps in and tells us what trouble he runs into. Any volunteers? Please sign up to nut-devel(a)mplayerhq.hu and inform us... - ods15

3 2