[MPlayer-dev-eng] NUT cleanup

[Michael Niedermayer]

Hi

On Fri, Sep 09, 2005 at 12:41:23PM -0400, Rich Felker wrote:
> 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.

ok, and stream_id==stream_count means all streams


> 
> 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?

i dont like this


> 
> 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...

we could add reserved fields or say even == v / odd == vb


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

hmm lets see how much space we loose in worst case, lets assume the
info packets are repeated every second and we have 1video 1audio 1subtitle
stream (more wouldnt be realistic for a very low bitrate stream)
Author,Title,Copyright,Description 35byte/sec
Encoder,Language,Disposition 3*29byte/sec
-> 122 byte/sec = 976bit/sec ~ 1kbit/sec iam not so sure this is 
insgnificant for very low bitrate


> 
> 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.

this should be changed


[...]
-- 
Michael