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-".
On Fri, Feb 29, 2008 at 03:25:12AM +0100, michael wrote:
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.
IMO this conflicts with the use of Disposition. For example, a stream is very likely both original and default, and it might instead be both dub and default if the person making the file is lame. I would hate to see correct dispositions go unlabelled because the creator of the file thought it more important to impose their idea of what should be default than to correctly label the streams. If default exists, it should be a completely different key, not folded into Disposition. Rich
Hi On Thu, Feb 28, 2008 at 09:48:37PM -0500, Rich Felker wrote:
On Fri, Feb 29, 2008 at 03:25:12AM +0100, michael wrote:
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.
IMO this conflicts with the use of Disposition. For example, a stream is very likely both original and default, and it might instead be both dub and default if the person making the file is lame. I would hate to see correct dispositions go unlabelled because the creator of the file thought it more important to impose their idea of what should be default than to correctly label the streams.
Stream 8 Disposition "default" Disposition "lyrics" Disposition "original" Stream 9 Disposition "lyrics" Disposition "dub" No problem here. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire
On Fri, Feb 29, 2008 at 04:17:09AM +0100, Michael Niedermayer wrote:
Hi
On Thu, Feb 28, 2008 at 09:48:37PM -0500, Rich Felker wrote:
On Fri, Feb 29, 2008 at 03:25:12AM +0100, michael wrote:
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.
IMO this conflicts with the use of Disposition. For example, a stream is very likely both original and default, and it might instead be both dub and default if the person making the file is lame. I would hate to see correct dispositions go unlabelled because the creator of the file thought it more important to impose their idea of what should be default than to correctly label the streams.
Stream 8 Disposition "default" Disposition "lyrics" Disposition "original"
Stream 9 Disposition "lyrics" Disposition "dub"
No problem here.
Hmm, is more than one copy of the same key valid? And how is that meant to be interpreted? I'm not necessarily opposed to the idea but I don't think it's well-specified at this point and I'd like to consider all the implications... Rich
On Thu, Feb 28, 2008 at 10:39:39PM -0500, Rich Felker wrote:
On Fri, Feb 29, 2008 at 04:17:09AM +0100, Michael Niedermayer wrote:
Hi
On Thu, Feb 28, 2008 at 09:48:37PM -0500, Rich Felker wrote:
On Fri, Feb 29, 2008 at 03:25:12AM +0100, michael wrote:
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.
IMO this conflicts with the use of Disposition. For example, a stream is very likely both original and default, and it might instead be both dub and default if the person making the file is lame. I would hate to see correct dispositions go unlabelled because the creator of the file thought it more important to impose their idea of what should be default than to correctly label the streams.
Stream 8 Disposition "default" Disposition "lyrics" Disposition "original"
Stream 9 Disposition "lyrics" Disposition "dub"
No problem here.
Hmm, is more than one copy of the same key valid?
yes
And how is that meant to be interpreted?
In the form that they all apply. "9 is a stream with translated lyrics"
I'm not necessarily opposed to the idea but I don't think it's well-specified at this point and I'd like to consider all the implications...
Well its intuitively meaningfull ... multiple authors multiple titles ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes
On Fri, Feb 29, 2008 at 12:58:48PM +0100, Michael Niedermayer wrote:
Hmm, is more than one copy of the same key valid?
yes
And how is that meant to be interpreted?
In the form that they all apply. "9 is a stream with translated lyrics"
I meant more broadly than just disposition.
I'm not necessarily opposed to the idea but I don't think it's well-specified at this point and I'd like to consider all the implications...
Well its intuitively meaningfull ... multiple authors
Yes, but probably in all other containers it's a single Author key with a value such as "Michael Niedermayer, Rich Felker, ..." This could also apply to disposition, but potentially makes using it harder for applications since they need to parse a sort of string list rather than just matching exact strings. On the other hand, multiple values for the same key likely does not fit well with an expected API of being able to query a key and get a value as the result.
multiple titles
Do we need meta-metainfo, i.e. language tags on the titles? :( Perhaps keys named Title-xxx where xxx is a language code? Rich
On Fri, Feb 29, 2008 at 02:09:12PM -0500, Rich Felker wrote:
On Fri, Feb 29, 2008 at 12:58:48PM +0100, Michael Niedermayer wrote:
Hmm, is more than one copy of the same key valid?
yes
And how is that meant to be interpreted?
In the form that they all apply. "9 is a stream with translated lyrics"
I meant more broadly than just disposition.
I'm not necessarily opposed to the idea but I don't think it's well-specified at this point and I'd like to consider all the implications...
Well its intuitively meaningfull ... multiple authors
Yes, but probably in all other containers it's a single Author key with a value such as "Michael Niedermayer, Rich Felker, ..."
This could also apply to disposition, but potentially makes using it harder for applications since they need to parse a sort of string list rather than just matching exact strings.
There are also problems with info packet repeation if there are several author tags. (add to list vs. repeated packet / already in the list)
On the other hand, multiple values for the same key likely does not fit well with an expected API of being able to query a key and get a value as the result.
I dont see how this could work, not with nor without multiple keys. Just an example: starttime= 10 end= 50 author= Michael Niedermayer starttime= 50 end= 90 author= Rich Felker
multiple titles
Do we need meta-metainfo, i.e. language tags on the titles? :( Perhaps keys named Title-xxx where xxx is a language code?
and title disposition (original, translated) :) And dont forget that Description, keywords, author and probably others need language as well. And after you added language to title, you will find out that there are several countries which use english but they use different titles for the same dvd. We at least need title-lang-country :) What about: A tag can contain a -LLL / -LLL-CC language and country postfix to indicate the language and country, the first tag should contain the default/original if multiple language variants of a tag are stored. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato
On 01/03/2008, Michael Niedermayer <michaelni@gmx.at> wrote:
On Fri, Feb 29, 2008 at 02:09:12PM -0500, Rich Felker wrote:
On Fri, Feb 29, 2008 at 12:58:48PM +0100, Michael Niedermayer wrote:
Yes, but probably in all other containers it's a single Author key with a value such as "Michael Niedermayer, Rich Felker, ..."
This could also apply to disposition, but potentially makes using it harder for applications since they need to parse a sort of string list rather than just matching exact strings.
There are also problems with info packet repeation if there are several author tags. (add to list vs. repeated packet / already in the list)
On the other hand, multiple values for the same key likely does not fit well with an expected API of being able to query a key and get a value as the result.
The way it works in email and HTTP headers is that multiple instances of a key are equivalent to one instance with the values concatenated, separated by commas. ie.: Author: Peter, Paul Author: Mary is equivalent to the single header: Author: Peter, Paul, Mary This allows an implementation to compare using a canonical representation of the value of a key. In HTTP, it allows each stage of content production to simply append values, without modifying earlier header text. It is also valid for an intermediate proxy to rewrite the headers in the canonical form. There may be similar use cases in media production and distribution, like where multiple departments in a studio add and process metadata. cheers, Conrad.
participants (4)
-
Conrad Parker -
michael -
Michael Niedermayer -
Rich Felker