[MPlayer-dev-eng] NUT cleanup

[Rich Felker]

On Sun, Sep 04, 2005 at 11:31:11PM +0300, Oded Shimon wrote:
> 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.

It's not repetition. The indices for each stream are presumably
independent.

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

Which checksum? Anyway they're all a checksum of the whole NUT packet
up to (but of course not including) the checksum itself.

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

Your implementation is broken if it's any more difficult to implement
one way than the other..

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

Last I heard, your muxer requires packets to already be in correct
interleaved order.. We need a sorting input wrapper with dts
calculation to make sure they're muxed correctly, and the unwrapped
muxer needs to reject packets that are out of order.

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

Please DO NOT make a muxer that ignores B frames. If it doesn't
support them it needs to check for a stream containing B frames and
exit with fatal error if it finds one.

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

:)

Rich