[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

Regarding info packets (again :( ...), I've been talking with Oded
about them and see some things I don't particularly like in the spec..

1. StreamId as a key/value pair to specify what stream the info packet
   describes. The reason I don't like it is that the info packet can't
   simply be copied when remuxing with different stream id's. You
   actually have to parse the packet, see if it contains a StreamId,
   update the value, and write the modified packet. Putting something
   like:
        stream_id                  v
   at the beginning of the info packet would be a lot cleaner imo. I
   think this was discussed once before, but that was before we had
   info streams too.

2. Info packet position? Presumably now they can go anywhere, but this
   doesn't seem useful since we have info streams.. Can we restrict
   them to go at the beginning right after the main headers, so that
   the demuxer can actually find them? And at most one info packet per
   stream, plus at most one global info packet?

3. Info fields table:

info_table[][2]={
        {NULL                   ,  NULL }, // end
        {NULL                   ,  NULL },
        {NULL                   , "UTF8"},
        {NULL                   , "v"},
        {NULL                   , "s"},
        {"StreamId"             , "v"},
        {"Author"               , "UTF8"},
        {"Titel"                , "UTF8"},
        {"Language"             , "UTF8"},
        {"Description"          , "UTF8"},
        {"Copyright"            , "UTF8"},
        {"Encoder"              , "UTF8"},
        {"Keyword"              , "UTF8"},
        {"Cover"                , "JPEG"},
        {"Cover"                , "PNG"},
        {"Disposition"          , "UTF8"},
};

   I don't like this for several reasons. The idea, if I understand
   correctly, is just to compress the data by providing an alternate
   storage format for common "well known" fields. Presumably the muxer
   would translate the key/type pairs to these id codes, and the
   demuxer would translate them back. The problems are:

   A. This is a fair amount of extra complexity/code and data table in
      muxer/demuxer for very little size savings.

   B. We can't ever add new "well known" fields to this table, even if
      we add new standard fields to the NUT spec, since old demuxers
      won't be able to translate the integer codes to key/type pairs.
      Even if you don't care about old demuxers knowing the key name,
      they _MUST_ know the type to know whether to parse the value as
      "v" or "vb". Thus the savings are limited to the few fields
      already in the table...

   IMO it would be much more beneficial to just use short efficient
   keys (like "lang" instead of "Language", etc.) whenever they're
   clear.

4. Info packet's key/value pair list is 0-terminated. This makes
   demuxing inefficient since you don't know the number of keys
   present to begin with, and you may have to realloc multiple times.
   Most other NUT structures tell the number of elements before the
   data.


Rich