March 2008 - NUT-devel - lists.mplayerhq.hu

[nut]: r657 - docs/nut.txt
by ods15 08 Mar '08

08 Mar '08

Author: ods15 Date: Sat Mar 8 17:25:51 2008 New Revision: 657 Log: Typo fix, main_flags should be in main header Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Sat Mar 8 17:25:51 2008 @@ -291,6 +291,7 @@ main_header: header_count_minus1 v for(i=0; i<header_count_minus1; i++) elision_header[i+1] vb + main_flags v reserved_bytes stream_header: @@ -422,7 +423,6 @@ info_packet: type= "v" } } - main_flags v reserved_bytes syncpoint:

1 0

main_flags in spec
by ods15＠ods15.dyndns.org 08 Mar '08

08 Mar '08

I just noticed this, main_flags is stored in info headers instead of the main header, I assume this is a typo? I'll commit the following soon... - ods15

2 1

[nut]: r644 - docs/nut.txt
by michael 04 Mar '08

04 Mar '08

Author: michael Date: Fri Feb 29 03:25:11 2008 New Revision: 644 Log: clarify default Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Fri Feb 29 03:25:11 2008 @@ -931,7 +931,10 @@ info packet types A demuxer MUST ignore unknown language and country codes instead of treating them as an error. "Disposition" - "original", "dub" (translated), "comment", "lyrics", "karaoke", "default" + "original", "dub" (translated), "comment", "lyrics", "karaoke", + "default" + Streams which the creator of the file intended to be played by + default. A player can follow this suggestion or ignore it. Note: If someone needs some others, please tell us about them, so we can add them to the official standard (if they are sane). Note: Nonstandard fields should be prefixed by "X-".

4 7

[nut]: r656 - docs/nut.txt
by michael 03 Mar '08

03 Mar '08

Author: michael Date: Mon Mar 3 20:04:04 2008 New Revision: 656 Log: Better phrasing by mans. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Mon Mar 3 20:04:04 2008 @@ -1026,8 +1026,8 @@ at least 1 keyframe every N seconds in e Furthermore, to start correct "presentation" (after seeking) it is necessary to have a decoded frame from every stream at approximately the same time. Thus it is important to have closely placed keyframes in all streams at least -once every N seconds. This is equivalent to having back pointers frequently -short. +once every N seconds. This is equivalent to having frequent, short back +pointers. Good example: Video: .....K...........................................K........... Audio: KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK

1 0

[nut]: r648 - docs/nut.txt
by michael 03 Mar '08

03 Mar '08

Author: michael Date: Mon Mar 3 14:50:19 2008 New Revision: 648 Log: Random Access (seeking) considerations Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Mon Mar 3 14:50:19 2008 @@ -1017,6 +1017,39 @@ The muxer SHOULD repeat non-mandatory he the overhead is not excessive. +Random Access (seeking) considerations: +--------------------------------------- +Decoding can only start at a keyframe. Thus if efficient seeking with at +least a granularity of N seconds is wanted, then it is neccessary to have +at least 1 keyframe every N seconds in every stream. + +Furthermore to start correct "presentation" (after seeking) it is neccessary +to have a decoded frame from every stream at approximately the same time. +Thus it is important to have closely placed keyframes in all streams at least +once every N seconds. This is equivalent of having back pointers frequently +short. +Good example: +Video: .....K...........................................K........... +Audio: KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK +Subtitle: ..K............................................K.....K....... +shortest back ptrs:<--o + <-----------------------------------------o + <-o + <---o +Bad example: +Video: .....K...........................................K........... +Audio: KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK +Subtitle: ..........................K.................................. +shortest back ptrs: <--------------------o + <----------------------o + +In the bad example a player would have to demux and decode half of the video +between the 2 keyrames to start correct playback if it favors the shortest +back ptr. + +The above 2 considerations are not specific to NUT. + + Index: ------

4 5

[nut]: r655 - docs/nut.txt
by diego 03 Mar '08

03 Mar '08

Author: diego Date: Mon Mar 3 18:06:47 2008 New Revision: 655 Log: two more typos Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Mon Mar 3 18:06:47 2008 @@ -1044,10 +1044,10 @@ shortest back ptrs: <----------------- <----------------------o In the bad example a player would have to demux and decode half of the video -between the 2 keyrames to start correct playback if it favors the shortest +between the 2 keyframes to start correct playback if it favors the shortest back pointer. A player could of course also choose to ignore subtitles and thus not display them between the video keyframe and subtitle frame. This -would avoid the decoding but not neccessarily demuxing and of course would +would avoid the decoding but not necessarily demuxing and of course would lead to incorrect display (no subtitles). An encoding application SHOULD thus try to reasonably align keyframes in time. This could be achieved by repeating subtitle packets at video keyframes (with appropriately adjusted start/end

1 0

[nut]: r654 - docs/nut.txt
by michael 03 Mar '08

03 Mar '08

Author: michael Date: Mon Mar 3 18:03:25 2008 New Revision: 654 Log: A few words on how the keyframes could be aligned. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Mon Mar 3 18:03:25 2008 @@ -1045,7 +1045,13 @@ shortest back ptrs: <----------------- In the bad example a player would have to demux and decode half of the video between the 2 keyrames to start correct playback if it favors the shortest -back pointer. +back pointer. A player could of course also choose to ignore subtitles and +thus not display them between the video keyframe and subtitle frame. This +would avoid the decoding but not neccessarily demuxing and of course would +lead to incorrect display (no subtitles). An encoding application SHOULD thus +try to reasonably align keyframes in time. This could be achieved by repeating +subtitle packets at video keyframes (with appropriately adjusted start/end +times in the subtitle packets if needed). The above considerations are not specific to NUT.

1 0

[nut]: r653 - docs/nut.txt
by diego 03 Mar '08

03 Mar '08

Author: diego Date: Mon Mar 3 18:00:11 2008 New Revision: 653 Log: misc spelling/wording/grammar fixes Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Mon Mar 3 18:00:11 2008 @@ -82,8 +82,8 @@ dts EOR frames End of relevance frames indicate that a given stream is not relevant - for presentation begining with the EOR frame and until the following - keyframe. This is primarely intended for periods were subtitles are + for presentation beginning with the EOR frame and until the following + keyframe. This is primarily intended for periods where subtitles are not displayed. But it is not limited to subtitles. @@ -1023,10 +1023,10 @@ Decoding can only start at a keyframe. T least a granularity of N seconds is wanted, then it is neccessary to have at least 1 keyframe every N seconds in every stream. -Furthermore to start correct "presentation" (after seeking) it is neccessary +Furthermore, to start correct "presentation" (after seeking) it is necessary to have a decoded frame from every stream at approximately the same time. Thus it is important to have closely placed keyframes in all streams at least -once every N seconds. This is equivalent of having back pointers frequently +once every N seconds. This is equivalent to having back pointers frequently short. Good example: Video: .....K...........................................K........... @@ -1045,7 +1045,7 @@ shortest back ptrs: <----------------- In the bad example a player would have to demux and decode half of the video between the 2 keyrames to start correct playback if it favors the shortest -back ptr. +back pointer. The above considerations are not specific to NUT. @@ -1089,15 +1089,15 @@ B. forward seeking 1a. Perform a binary search on the syncpoint timestamps finding the one which is smallest and >= the target timestamp. 1b. Perform a binary search on the syncpoint back pointers finding the - smallest one which has a back ptr >= the position of what was found in 1. + smallest one which has a back pointer >= the position found in 1. 2. Follow the back pointer to the corresponding syncpoint. -Alternatively a demuxer can search for a shorter back ptr (which ensures that -keyframes in all streams are closer together) before 2. +Alternatively a demuxer can search for a shorter back pointer (which ensures +that keyframes in all streams are closer together) before 2. One way to do this for backward seeking is: -if the back ptr is longer than the demuxer wants, step back by half the ptr, -search for another syncpoint and repeat until either the ptr is short enough -or the search went too far. +If the back pointer is longer than the demuxer wants, step back by half the +pointer, search for another syncpoint and repeat until either the pointer is +short enough or the search went too far. Seeking with an index (non-normative):

1 0

[nut]: r652 - docs/nut4cc.txt
by diego 03 Mar '08

03 Mar '08

Author: diego Date: Mon Mar 3 17:59:29 2008 New Revision: 652 Log: misc spelling/wording fixes Modified: docs/nut4cc.txt Modified: docs/nut4cc.txt ============================================================================== --- docs/nut4cc.txt (original) +++ docs/nut4cc.txt Mon Mar 3 17:59:29 2008 @@ -1,10 +1,10 @@ -This list lists fourcc codes and the codecs they identify. +This list enumerates fourcc codes and the codecs they identify. -Codecs which are not in this list but have a standard fourcc in avi can be +Codecs which are not in this list but have a standard fourcc in AVI can be used with the AVI fourcc in nut as well. -Codecs which are in this list but are not used with the same fourcc in avi +Codecs which are in this list but are not used with the same fourcc in AVI should be reported to us! (these maybe a typo) -Codecs which are in this list and in avi with the same fourcc as well as +Codecs which are in this list and in AVI with the same fourcc as well as other fourccs, SHOULD use the fourcc specified here. For codecs which do not have a fourcc in AVI nor this list, please contact us so we can add them to the list. @@ -31,14 +31,14 @@ IV50 Indeo 5.0 LJPG ITU JPEG (lossless) MJLS ITU JPEG-LS MJPG ITU JPEG -MPG4 MS MPEG4v1 (!NOT ISO MPEG4!) -MP42 MS MPEG4v2 -MP43 MS MPEG4v3 -MP4V ISO MPEG4 Part 2 Video - !for non compliant mpeg4 like old divx4/odivx use the respective - fourcc, this fourcc is only for fully compliant mpeg4! -mpg1 ISO MPEG1 Video -mpg2 ISO MPEG2 Video +MPG4 MS MPEG-4v1 (!NOT ISO MPEG-4!) +MP42 MS MPEG-4v2 +MP43 MS MPEG-4v3 +MP4V ISO MPEG-4 Part 2 Video + !for non-compliant MPEG-4 like old divx4/odivx use the respective + fourcc, this fourcc is only for fully comliant MPEG-4! +mpg1 ISO MPEG-1 Video +mpg2 ISO MPEG-2 Video MRLE MS RLE MSVC MS Video 1 RT21 Indeo 2.1 @@ -46,10 +46,10 @@ RV10 Real Video 1.0 RV20 Real Video 2.0 RV30 Real Video 3.0 RV40 Real Video 4.0 -SNOW FFmpeg snow +SNOW FFmpeg Snow SVQ1 Sorenson Video 1 SVQ3 Sorenson Video 3 -theo Xiph theora +theo Xiph Theora TM20 Truemotion 2.0 UMP4 non compliant MPEG4 generated by UB Video MPEG-4 VCR1 ATI VCR1 @@ -77,14 +77,14 @@ Y800 8bit Gray 444P Planar 4:4:4 YUV UYVY Packed 4:2:2 YUV (UYVY) YUY2 Packed 4:2:2 YUV (YUYV) -RGB[15] Packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb), little endian [NOT in AVI] -BGR[15] Packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), little endian [NOT in AVI] -RGB[16] Packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb), little endian [NOT in AVI] -BGR[16] Packed BGR 5:6:5, 16bpp, (msb) 5B 6G 5R(lsb), little endian [NOT in AVI] -[15]BGR Packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb), big endian [NOT in AVI] -[15]RGB Packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), big endian [NOT in AVI] -[16]BGR Packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb), big endian [NOT in AVI] -[16]RGB Packed BGR 5:6:5, 16bpp, (msb) 5B 6G 5R(lsb), big endian [NOT in AVI] +RGB[15] Packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb), little-endian [NOT in AVI] +BGR[15] Packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), little-endian [NOT in AVI] +RGB[16] Packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb), little-endian [NOT in AVI] +BGR[16] Packed BGR 5:6:5, 16bpp, (msb) 5B 6G 5R(lsb), little-endian [NOT in AVI] +[15]BGR Packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb), big-endian [NOT in AVI] +[15]RGB Packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb), big-endian [NOT in AVI] +[16]BGR Packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb), big-endian [NOT in AVI] +[16]RGB Packed BGR 5:6:5, 16bpp, (msb) 5B 6G 5R(lsb), big-endian [NOT in AVI] RGBA Packed RGBA 8:8:8:8, 32bpp, RGBA [NOT in AVI] BGRA Packed RGBA 8:8:8:8, 32bpp, BGRA [NOT in AVI] ABGR Packed RGBA 8:8:8:8, 32bpp, ABGR [NOT in AVI] @@ -95,12 +95,12 @@ BGR[24] Packed RGB 8:8:8, 24bpp BGR [NOT Raw audio: [x] is an byte with value x, [NOT in AVI] ALAW A-LAW ULAW MU-LAW -P<type><interleaving><bits> little endian PCM -<bits><interleaving><type>P big endian PCM +P<type><interleaving><bits> little-endian PCM +<bits><interleaving><type>P big-endian PCM <type> is S for signed integer, U for unsigned integer, F for IEEE float <interleaving> is D for default (left, right) <bits> is 8/16/24/32 -PFD[32] would for example be signed 32 bit little endian IEEE float +PFD[32] would for example be signed 32 bit little-endian IEEE float Subtitles: UTF8 Raw utf8 @@ -108,5 +108,4 @@ SSA[0] SubStation Alpha DVDS DVD subtitles DVBS DVB subtitles - -FIXME dv/gray16/audio codecs/multi chan interleaving +FIXME dv/gray16/audio codecs/multi channel interleaving

1 0

[nut]: r651 - docs/nutissues.txt
by diego 03 Mar '08

03 Mar '08

Author: diego Date: Mon Mar 3 17:58:44 2008 New Revision: 651 Log: misc spelling fixes Modified: docs/nutissues.txt Modified: docs/nutissues.txt ============================================================================== --- docs/nutissues.txt (original) +++ docs/nutissues.txt Mon Mar 3 17:58:44 2008 @@ -16,7 +16,7 @@ C. buffer fullness in seconds D. buffer fullness in bytes E. transmit time stamps -Values in bytes are sensitiv to packet loss, which can delay initial startup. +Values in bytes are sensitive to packet loss, which can delay initial startup. These can be stored in one of the following @@ -122,34 +122,34 @@ Implemented Issue small-frames ------------------ -The original intent of nut frames was that 1 container frame == 1 codec -frame. Though this does not seem to be explicitly written in nut.txt. +The original intent of NUT frames was that 1 container frame == 1 codec +frame, albeit this does not seem to be explicitly written in nut.txt. Also it is inefficient for very small frames, AMR-NB for example has 6-32 bytes per frame. Solutions: A. Enforce 1 container frame == 1 codec frame even if it causes 10% overhead. B. Allow multiple frames as long as the whole packet is less than some - fixed minimum in bytes (like 256byte) + fixed minimum in bytes (like 256byte). C. Allow multiple frames as long as the whole packet is less than some fixed minimum in bytes (like 256byte) and the codec uses a constant framesize in samples. D. Use header compression, that is allow to store the first (few) bytes of a codec frame together with its size in the framecode table. This would allow us to store the size of a frame without any redundancy. - Thus effectivly avoiding the overhead small frames cause. + Thus effectively avoiding the overhead small frames cause. It seems the consensus is: A+D With the specified bounds Issue pcm-frames ---------------- -No word is said about how many or few PCM samples should be in a frame. +No word is said about how many or how few PCM samples should be in a frame. Solutions: -A. Define an maximum number of samples (like 512) -B. Define an maximum timespam (like 0.1 sec) -C. Define an maximum number of bytes (like 1024) +A. Define a maximum number of samples (like 512). +B. Define a maximum timespam (like 0.1 sec). +C. Define a maximum number of bytes (like 1024). Implemented: A @@ -175,7 +175,7 @@ C. New field in the stream header D. Only allow 1 standard interleaving What about the interleaving of non raw codecs, do all specify the -interleaving, or does any leave it to the container? If so, our options +interleaving, or do any leave it to the container? If so, our options would be down to only C. Also a field specific to just raw does not belong in the stream headers.

1 0