[MPlayer-dev-eng] finalizing nut!

D Richard Felker III dalias at aerifal.cx
Tue May 25 20:51:47 CEST 2004


ok, nut and the next mplayer release are both running a little behind
schedule. but no need to rush, they'll be good when they're ready.
here's my todo list for what needs to be done to finalize nut and
release:

remove deprecated stuff:
- index_flag (per-stream indices no longer exist)
- stream_id in index (likewise)

add the following:
- max_short_distance (max dist between short startcodes)
- specify requirements of fixed_fps (timebase==framerate etc)
- requirements of index (end of file, how to find beginning, etc)
- startcode overrides?? (not sure...good or bad?)
- extra language flags in stream header (default=recommended default
  for playback, original=original language, possibly also
  supplemental=never select by default, e.g. commentary track) without
  these it's very difficult for a player to do what the user intends
  without manual per-file configuration!
- clarify whether it's legal for timestamps to mismatch samplecounts
- express interleaving rules clearly and use the word MUST...

change:
- language code standard should be clearly specified. i vote for
  3-letter iso lang codes!
- update features/goals: header sizes, overhead %, ...?

documentation:

imo there should be a 'formal spec' document like we have now, but
also a document that explains the motivations & purpose behind the
design of nut, how it's intended to work and be used, etc. it should
start by explaining the principal data storage tricks (vlc and frame
codes), then give an overview of nut file structure. examples would be
helpful. i think this is really important to getting other projects to
adopt nut. if it's just a confusing formal spec and they don't
understand the point, no one will use it. i can probably write this
document if needed.

in addition, we need a press release that hypes the advantages of nut
(low overhead, zero latency, exact pts, usefulness of arbitrary time
base for editing and mixed-framerate content, usefulness of language
flags, extensibility, error recovery, ...). this can be pretty simple.

finally, i think we need a website. i'm in favor of hosting it on
fsn.hu if possible, rather than mphq, so it doesn't look
mplayer-centric. maybe someone could volunteer to design it. diego...?
:)

i can't think of anything else yet...

rich




More information about the MPlayer-dev-eng mailing list