[PATCH 1/2] nut: add a minor version field
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- docs/nut.txt | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/docs/nut.txt b/docs/nut.txt index 7969e3c..44198c1 100644 --- a/docs/nut.txt +++ b/docs/nut.txt @@ -1,5 +1,5 @@ ================================== -NUT Open Container Format 20080202 +NUT Open Container Format 20131223 ================================== @@ -243,6 +243,8 @@ reserved_headers main_header: version v + if (version > 3) + minor_version v stream_count v max_distance v time_base_count v @@ -463,6 +465,12 @@ info_startcode (f(64)) version (v) NUT version. The current value is 3. All lower values are pre-freeze. +minor_version (v) + NUT minor_version. This represents minor changes in the specification + which do not affect compatibility. Demuxers MUST NOT reject files + based on this value. + The current value is 0 + stream_count (v) number of streams in this file -- 1.7.9.5
This variant is simpler and has less overhead than the previous It is not compatible with existing demuxers though, the reasoning here is that as side data is essential for presentation of a stream demuxer support is neccessary anyway. Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- docs/nut.txt | 98 ++++++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 74 insertions(+), 24 deletions(-) diff --git a/docs/nut.txt b/docs/nut.txt index 44198c1..e414904 100644 --- a/docs/nut.txt +++ b/docs/nut.txt @@ -353,6 +353,46 @@ frame: } data +data: + if (frame_flags&FLAG_SM_DATA) { + side_data + meta_data + } + frame_data + +side_data + sm_data + +meta_data + sm_data + +sm_data: + 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" + } + } + + index: max_pts t syncpoints v @@ -401,30 +441,7 @@ info_packet: 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" - } - } + meta_data reserved_bytes syncpoint: @@ -651,6 +668,8 @@ flags[frame_code], frame_flags (v) otherwise data_size_msb is 0. 6 FLAG_CHECKSUM If set, the frame header contains a checksum. 7 FLAG_RESERVED If set, reserved_count is coded in the frame header. + 8 FLAG_SM_DATA If set, side/meta data is stored with the frame data. + This flag MUST NOT be set in version < 4 10 FLAG_HEADER_IDX If set, header_idx is coded in the frame header. 11 FLAG_MATCH_TIME If set, match_time_delta is coded in the frame header @@ -700,6 +719,37 @@ pts_delta[frame_code] (s) reserved_count[frame_code] (v) MUST be <256. +sm_data / side_data / meta_data + This data structure is used both in frames for per frame side and metadata + as well as info tags for metadata covering the whole file, a stream + chapter or other. + Metadata is data that is about the actual data and generally not essential + for correct presentation + Sidedata is semantically part of the data and essential for its correct + presentation. The same syntax is used by both for simplicity. + Types of per frame side data: + "Channels", "ChannelLayout", "SampleRate", "Width", "Height" + This frame changes the number of channels, the channel layout, ... to + the given value (ChannelLayout vb, else v) + If used in any frame of a stream then every keyframe of the stream + SHOULD carry such sidedata to allow seeking. + "Extradata", "Palette" + This frame changes the codec_specific_data or palette to the given + value (vb) + If used in any frame of a stream then every keyframe of the stream + SHOULD carry such sidedata to allow seeking. + "CodecSpecificSide<num>" + Codec specific side data, equivalent to matroskas BlockAdditional (vb) + the "<num>" should be replaced by a number identifying the type of + side data, it is equivalent/equal to BlockAddId in matroska. + "SkipStart", "SkipEnd" + The decoder should skip/drop the specified number of samples at the + start/end of this frame (v) + "UserData<identifer here>" + User specific side data, the "<identifer here>" should be replaced + by a globally unique identifer of the project that + uses/creates/understands the side data. For example "UserDataFFmpeg" + data_size data_size = data_size_lsb + data_size_msb * data_size_mul ; The size of the following frame, including a possible elision header. -- 1.7.9.5
On 23/12/13 03:21, Michael Niedermayer wrote:
This variant is simpler and has less overhead than the previous It is not compatible with existing demuxers though, the reasoning here is that as side data is essential for presentation of a stream demuxer support is neccessary anyway.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- docs/nut.txt | 98 ++++++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 74 insertions(+), 24 deletions(-)
diff --git a/docs/nut.txt b/docs/nut.txt index 44198c1..e414904 100644 --- a/docs/nut.txt +++ b/docs/nut.txt @@ -353,6 +353,46 @@ frame: } data
+data: + if (frame_flags&FLAG_SM_DATA) { + side_data + meta_data + } + frame_data + +side_data + sm_data + +meta_data + sm_data
+sm_data: + 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" + } + }
Probably would be more readable moving the above next to "data:" The rest seems as fine as before.
On Mon, Dec 23, 2013 at 06:30:24AM +0100, Luca Barbato wrote:
On 23/12/13 03:21, Michael Niedermayer wrote:
This variant is simpler and has less overhead than the previous It is not compatible with existing demuxers though, the reasoning here is that as side data is essential for presentation of a stream demuxer support is neccessary anyway.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- docs/nut.txt | 98 ++++++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 74 insertions(+), 24 deletions(-)
diff --git a/docs/nut.txt b/docs/nut.txt index 44198c1..e414904 100644 --- a/docs/nut.txt +++ b/docs/nut.txt @@ -353,6 +353,46 @@ frame: } data
+data: + if (frame_flags&FLAG_SM_DATA) { + side_data + meta_data + } + frame_data + +side_data + sm_data + +meta_data + sm_data
+sm_data: + 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" + } + }
Probably would be more readable moving the above next to "data:"
moved
The rest seems as fine as before.
applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato
On 23.12.2013, at 03:21, Michael Niedermayer <michaelni@gmx.at> wrote:
This variant is simpler and has less overhead than the previous It is not compatible with existing demuxers though, the reasoning here is that as side data is essential for presentation of a stream demuxer support is neccessary anyway.
This seems to split things into "side data" which is defined as essential for decoding and metadata. But this seems a bit too limited to me. For example I believe we now have side data in FFmpeg that contains CC subtitle data. It is clearly not necessary for decoding and it clearly isn't metadata either. I guess it maybe shouldn't be written in this structure at all, but would/will the FFmpeg muxer do something sensible with it? I think it would be good to make sure we have enough flexibility to represent stuff we did not yet think of, though I fully approve of the "essential to decode" distinction in principle. It's just that we don't really have this information if its essential in FFmpeg, so I'd suspect we might end up generating lots of invalid files (due to them having non-essential data in side data for example).
On Mon, Dec 23, 2013 at 01:28:16PM +0100, Reimar Döffinger wrote:
On 23.12.2013, at 03:21, Michael Niedermayer <michaelni@gmx.at> wrote:
This variant is simpler and has less overhead than the previous It is not compatible with existing demuxers though, the reasoning here is that as side data is essential for presentation of a stream demuxer support is neccessary anyway.
This seems to split things into "side data" which is defined as essential for decoding and metadata. But this seems a bit too limited to me. For example I believe we now have side data in FFmpeg that contains CC subtitle data. It is clearly not necessary for decoding and it clearly isn't metadata either.
its not neccessary for decoding the video but it is neccessary for presentation of the video where audio cannot be used, like in case of a loud environment, hearing impairment or insufficient language compatibility between the language used in the audio and the listener so i would argue that it qualifies as side data if its not in its own stream/track
I guess it maybe shouldn't be written in this structure at all, but would/will the FFmpeg muxer do something sensible with it?
Iam not sure which side data type you speak of exactly?
I think it would be good to make sure we have enough flexibility to represent stuff we did not yet think of,
Its hard to make sure that we support things that we did not think of. If one asks the question "what did we not think of" well maybe side data per slice or per macroblock or metadata for a subset of pixels in a picture These could be supprted by including the "where/what" in the "key/name" tough like "Person-RectXY[50,70-200,30]", "guy fawkes" "Slice56-FirstMV", "12.25,89" iam not sure how usefull that is though ...
though I fully approve of the "essential to decode" distinction in principle. It's just that we don't really have this information if its essential in FFmpeg, so I'd suspect we might end up generating lots of invalid files (due to them having non-essential data in side data for example).
id assume all metadata would use AV_PKT_DATA_STRINGS_METADATA or AV_PKT_DATA_METADATA_UPDATE and the rest would be side data. if a new field that represents metadata is added to ffmpeg but not to nut and if our nut muxer would store unknown types (it does not currently, but would with the proposed patch, but that could be changed) and the input would contain that new field then the muxer would create a file that contains a frame with a side data element that is "Junk" a demuxer either would ignore the side data or extract it back into the new metadata field opaquely. While this would be incorrect in some sense, as it should have been stored in metadata instead, i dont see how it could break anything. Also there are quite a few ifs in there and id consider such "storing in the wrong list" a bug in the implementation [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them.
On 23/12/13 03:21, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- docs/nut.txt | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/docs/nut.txt b/docs/nut.txt index 7969e3c..44198c1 100644 --- a/docs/nut.txt +++ b/docs/nut.txt @@ -1,5 +1,5 @@ ================================== -NUT Open Container Format 20080202 +NUT Open Container Format 20131223 ==================================
@@ -243,6 +243,8 @@ reserved_headers
main_header: version v + if (version > 3) + minor_version v stream_count v max_distance v time_base_count v @@ -463,6 +465,12 @@ info_startcode (f(64)) version (v) NUT version. The current value is 3. All lower values are pre-freeze.
+minor_version (v) + NUT minor_version. This represents minor changes in the specification + which do not affect compatibility. Demuxers MUST NOT reject files + based on this value. + The current value is 0 +
Looks fine.
On Mon, Dec 23, 2013 at 06:31:25AM +0100, Luca Barbato wrote:
On 23/12/13 03:21, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- docs/nut.txt | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/docs/nut.txt b/docs/nut.txt index 7969e3c..44198c1 100644 --- a/docs/nut.txt +++ b/docs/nut.txt @@ -1,5 +1,5 @@ ================================== -NUT Open Container Format 20080202 +NUT Open Container Format 20131223 ==================================
@@ -243,6 +243,8 @@ reserved_headers
main_header: version v + if (version > 3) + minor_version v stream_count v max_distance v time_base_count v @@ -463,6 +465,12 @@ info_startcode (f(64)) version (v) NUT version. The current value is 3. All lower values are pre-freeze.
+minor_version (v) + NUT minor_version. This represents minor changes in the specification + which do not affect compatibility. Demuxers MUST NOT reject files + based on this value. + The current value is 0 +
Looks fine.
applied thanks, and merry christmess [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
participants (3)
-
Luca Barbato -
Michael Niedermayer -
Reimar Döffinger