[MPlayer-dev-eng] NUT cleanup

[Oded Shimon]

On Sun, Sep 04, 2005 at 09:15:41PM +0200, Luca Barbato wrote:
> Rich Felker wrote:
> > Most definitely not!!
> > Subtitle has a 'codec' just like audio and video, and has a specific
> > interpretation that should be supported by all players. Metadata is
> > just the same useless crap that can be put in info packets, tagged
> > key/value pairs, except that it's muxed in the file rather than in a
> > global header so it can represent info that changes (such as new song
> > title on a radio).
> 
> Metadata should have a codec attached too, think about overlay
> information for documentaries expressed as vector graphics and text.
> 
> You'd put that as subtitle or metadata?

What exactly is Metadata??...

several last problems:
1. Subtitle stream type needs to be defined, metadata too.

2. whats colorspace_type? is it needed?...

3. The spec doesn't say how you put the index "per stream", it only says to 
put a single index... Rich said entire index should be repeated for each 
stream, spec should mention this.

4. From where until where is the checksum calculated?... The spec doesn't 
say this either.

5. To extremely reduce both muxer and demuxer complexity, i suggest 
'forward_ptr' should only be the length from right AFTER the vlc of the 
forward_ptr until the end of the checksum, NOT from the begginning of the 
startcode. Also I think the checksum should be only of this region too. 
This is not any less robust, it's just less of a pain in the ass to 
implement. Unless I'm missing something. (if your forward_ptr is broken, or 
your data is broken, or your crc is broken, you'll still get same results 
as the current behavior...)


I've completed my own independant implementation of the muxer, it conforms, 
but it does no input error checking, and could be much smarter than it is 
now (better frame code tables etc.). I'm now working on atleast a working 
demuxer.

Alex has created a new CVS Repository, /cvsroot/nut with 'libnut' and 
'nututils' direcotires. When I have a "barely complete" and working 
implementation of both muxer and demuxer, I'll commit. We are also waiting 
for Atilla to create dedicated mailing lists.

I am now looking for a brave individual that will start working on a 
'nutmerge' util, that can atleast read an AVI file and use my NUT muxer API 
to create a nice conforming NUT file (for now, disregard B frames, we'll 
add that later too..). Attached here is the nut.h API header, and an 
example muxer using /dev/urandom . Feel free to flame me to death on me 
making it a completely broken/stupid API. I've never written or even read a 
muxer implementation.

- ods15
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nut.h
Type: text/x-chdr
Size: 1337 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050904/f2c6f39c/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: random.c
Type: text/x-csrc
Size: 1659 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050904/f2c6f39c/attachment.c>