: r644 - docs/nut.txt

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-".
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On 01/03/2008, Michael Niedermayer <michaelnigmx.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.
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel