- NUT-devel - lists.mplayerhq.hu

[nut]: r589 - docs/nut.txt
by diego 05 Feb '08

05 Feb '08

Author: diego Date: Wed Feb 6 00:32:34 2008 New Revision: 589 Log: typo fixes Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Wed Feb 6 00:32:34 2008 @@ -497,7 +497,7 @@ stream_class (v) 0 video 1 audio 2 subtitles - 3 userdata + 3 user data Note: The remaining values are reserved and MUST NOT be used. A demuxer MUST ignore streams with reserved classes. @@ -576,7 +576,7 @@ stream_flags (v) 1 FLAG_FIXED_FPS indicates that the fps is fixed codec_specific_data (vb) - Private global data for a codec (could be huffman tables or ...). + Private global data for a codec (could be Huffman tables or ...). If a codec has a global header it SHOULD be placed in here instead of at the start of every keyframe. The exact format is specified in the codec specification. @@ -684,7 +684,7 @@ match_time_delta of previous frames (that is the frames are virtually identical no matter if decoding started from the very first frame or from this keyframe). If its value is 1-(1<<62) then match_time_delta is unspecified, that is - the muxer didnt have enough knowledge to set it. + the muxer did not have enough knowledge to set it. A muxer MUST only set it to 1-(1<<62) if it does not know the correct value. That is, it is not allowed to randomly discard known values.

1 0

[nut]: r587 - docs/nut.txt
by michael 05 Feb '08

05 Feb '08

Author: michael Date: Tue Feb 5 15:30:26 2008 New Revision: 587 Log: Fixes to make match_time_delta storeable in the framecode. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Tue Feb 5 15:30:26 2008 @@ -619,7 +619,7 @@ flags[frame_code], frame_flags (v) 6 FLAG_CHECKSUM If set, the frame header contains a checksum. 7 FLAG_RESERVED If set, reserved_count is coded in the frame header. 11 FLAG_MATCH_TIME If set, match_time_delta is coded in the frame - header, otherwise its 0. + header 12 FLAG_CODED If set, coded_flags are stored in the frame header. 13 FLAG_INVALID If set, frame_code is invalid. @@ -679,7 +679,6 @@ coded_pts (v) pts = ( (pts_lsb - delta) & mask ) + delta match_time_delta - If FLAG_MATCH_TIME is not set, then this is 0 This is the time difference in stream timebase units from the pts at which the output from the decoder has converged independent from the availability of previous frames (that is the frames are virtually identical no matter

1 0

[nut]: r586 - docs/nut.txt
by michael 05 Feb '08

05 Feb '08

Author: michael Date: Tue Feb 5 15:14:01 2008 New Revision: 586 Log: Add match_time_delta to the framecode table. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Tue Feb 5 15:14:01 2008 @@ -247,6 +247,7 @@ main_header: tmp_pts=0 tmp_mul=1 tmp_stream=0 + tmp_match=0 for(i=0; i<256; ){ tmp_flag v tmp_fields v @@ -259,7 +260,8 @@ main_header: else tmp_res=0 if(tmp_fields>5) count v else count= tmp_mul - tmp_size - for(j=6; j<tmp_fields; j++){ + if(tmp_fields>6) tmp_match s + for(j=7; j<tmp_fields; j++){ tmp_reserved[i] v } for(j=0; j<count && i<256; j++, i++){ @@ -274,6 +276,7 @@ main_header: data_size_lsb[i]= tmp_size + j; pts_delta[i]= tmp_pts; reserved_count[i]= tmp_res; + match_time_delta[i]= tmp_match; } } reserved_bytes

2 1

[nut]: r585 - docs/nut.txt
by diego 05 Feb '08

05 Feb '08

Author: diego Date: Tue Feb 5 14:27:54 2008 New Revision: 585 Log: spelling/wording Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Tue Feb 5 14:27:54 2008 @@ -678,7 +678,7 @@ coded_pts (v) match_time_delta If FLAG_MATCH_TIME is not set, then this is 0 This is the time difference in stream timebase units from the pts at which - the output from the decoder has converged independant of the availability + the output from the decoder has converged independent from the availability of previous frames (that is the frames are virtually identical no matter if decoding started from the very first frame or from this keyframe). @@ -888,15 +888,15 @@ info packet types of decoding it. "Depends" v (stream id) - This stream depends on the specified stream. That is if its - unavailable then this stream cannot be decoded. This is used to store - dependancies for scalability for example. + This stream depends on the specified stream. That is if the specified + stream is unavailable then this stream cannot be decoded. This is used + to store dependencies for scalability for example. "Uses" v (stream id) - This stream can use the specified stream. But its existence is not - mandatory for decoding this stream. Although if its unavailable - quality might suffer. Examples are font attachments or higher quality - samples from music instruments. + This stream can use the specified stream. But the existence of the + specified stream is not mandatory for decoding this stream, although + quality might suffer if it is unavailable. Examples: font attachments + or higher quality samples from musical instruments "UsesFont" "Times New Roman", "Arial", ... FIXME should we use the filename instead? is there some other unique way to identify fonts? @@ -942,12 +942,12 @@ in a file). There MUST be a syncpoint immediately before the first frame after any headers. -The main header is mandatory, so are all stream headers except thouse for -redundant and enhanchement streams. So for example if the file contains 2 -independant video streams encoding the same content at 2 different bitrates. +The main header is mandatory, so are all stream headers except those for +redundant and enhancement streams. So for example if the file contains 2 +independent video streams encoding the same content at 2 different bitrates. Then only one is mandatory, which that is, is at the discretion of the muxer. -Enhancement streams like font attachments are also non mandatory. -The muxer SHOULD repeat non mandatory headers like mandatory ones if +Enhancement streams like font attachments are also non-mandatory. +The muxer SHOULD repeat non-mandatory headers like mandatory ones if the overhead is not excessive.

1 0

[nut] [propchange]: r581 - svn:log
by diego 05 Feb '08

05 Feb '08

Author: diego Revision: 581 Property Name: svn:log Action: modified Property diff: --- old property value +++ new property value @@ -1 +1 @@ -Dependancy info. +dependency info

1 0

[nut]: r581 - docs/nut.txt
by michael 05 Feb '08

05 Feb '08

Author: michael Date: Mon Feb 4 23:40:57 2008 New Revision: 581 Log: Dependancy info. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Mon Feb 4 23:40:57 2008 @@ -886,6 +886,17 @@ info packet types This stream is a superior alternative (higher resolution or otherwise) of the given stream. It should be preferred if the decoder is capable of decoding it. + "Depends" + v (stream id) + This stream depends on the specified stream. That is if its + unavailable then this stream cannot be decoded. This is used to store + dependancies for scalability for example. + "Uses" + v (stream id) + This stream can use the specified stream. But its existence is not + mandatory for decoding this stream. Although if its unavailable + quality might suffer. Examples are font attachments or higher quality + samples from music instruments. "UsesFont" "Times New Roman", "Arial", ... FIXME should we use the filename instead? is there some other unique way to identify fonts?

4 4

redundant documents in the repository
by Diego Biurrun 05 Feb '08

05 Feb '08

In the repository we have docs/oggless-xiph-codecs.txt src/trunk/docs/draft-xiph-oggless-00.xml The former was written by Michael, the latter by Alex. What's it going to be? Diego

3 13

[nut]: r584 - in docs: draft-xiph-oggless-00.xml oggless-xiph-codecs.txt
by diego 05 Feb '08

05 Feb '08

Author: diego Date: Tue Feb 5 11:00:57 2008 New Revision: 584 Log: Remove outdated drafts about storing Xiph codecs in containers other than Ogg. The information has found a more permanent home at http://wiki.xiph.org/Oggless Removed: docs/draft-xiph-oggless-00.xml docs/oggless-xiph-codecs.txt

1 0

[nut]: r583 - docs/nut.txt
by michael 04 Feb '08

04 Feb '08

Author: michael Date: Tue Feb 5 00:06:29 2008 New Revision: 583 Log: More generic statement. Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Tue Feb 5 00:06:29 2008 @@ -947,7 +947,7 @@ redundant and enhanchement streams. So f independant video streams encoding the same content at 2 different bitrates. Then only one is mandatory, which that is, is at the discretion of the muxer. Enhancement streams like font attachments are also non mandatory. -The muxer SHOULD repeat non mandatory stream headers like mandatory ones if +The muxer SHOULD repeat non mandatory headers like mandatory ones if the overhead is not excessive.

1 0

[nut]: r582 - docs/nut.txt
by michael 04 Feb '08

04 Feb '08

Author: michael Date: Tue Feb 5 00:05:01 2008 New Revision: 582 Log: Make nut capable to handle attachments. Alternative suggestions are welcome Modified: docs/nut.txt Modified: docs/nut.txt ============================================================================== --- docs/nut.txt (original) +++ docs/nut.txt Tue Feb 5 00:05:01 2008 @@ -923,8 +923,8 @@ stream_header (id=1) ... stream_header (id=n) -Headers may be repeated, but if they are, then they MUST all be repeated -together and repeated headers MUST be identical. +Headers may be repeated, but if they are, then all mandatory headers MUST be +repeated and repeated headers MUST be identical. Each set of repeated headers not at the beginning or end of the file SHOULD be stored at the earliest possible position after 2^x where x is an integer. @@ -934,12 +934,22 @@ So the headers may be repeated at 4102 i Note: This allows an implementation reading the file to locate backup headers in O(log filesize) time as opposed to O(filesize). -Headers MUST be placed at least at the start of the file and immediately before +All headers MUST be placed at least at the start of the file. +Mandatory headers MUST additionally be placed immediately before the index or at the end of the file if there is no index. -Headers MUST be repeated at least twice (so they exist three times in a file). +Mandatory headers MUST be repeated at least twice (so they exist three times +in a file). There MUST be a syncpoint immediately before the first frame after any headers. +The main header is mandatory, so are all stream headers except thouse for +redundant and enhanchement streams. So for example if the file contains 2 +independant video streams encoding the same content at 2 different bitrates. +Then only one is mandatory, which that is, is at the discretion of the muxer. +Enhancement streams like font attachments are also non mandatory. +The muxer SHOULD repeat non mandatory stream headers like mandatory ones if +the overhead is not excessive. + Index: ------

1 0