[MPlayer-dev-eng] NUT cleanup

[Michael Niedermayer]

Hi

On Mon, Sep 05, 2005 at 01:42:38PM +0300, Oded Shimon wrote:
[...]
> > > 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.
> 
> Including the startcode?.. the current lavf/nut.c as far as i can tell does 
> NOT include the startcode in the checksum.

and it should not be included, as damage to the startcode assuming you can 
still identify it will not be a problem for parsing the packet


> 
> > > 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..
> 
> Possibly, but it kind of a problem - forward_ptr includes it's own size! 
> and since it's a VLC, by adding it's own size, it could grow! which is why 
> I must:
> 
> 1. in the muxer, add a 0x80 padding
> 2. in the demuxer, when reading it, I must remember/check its length - I 
> had to re-implement get_v() privately for the packet header reader for 
> this.
> 
> Granted, complexity is not THAT much worse, it's about 15 lines more code 
> total in the muxer and demuxer. But is it a necessary complexity??.. Or am 
> I still doing this broken and I should not be encountering this complexity?

iam not against changing the forward_ptr to not cover itself + the startcode
if every one thinks this is simpler, for lavf its the same
the bigest reason against the change is that it breaks compatibility ...

[...]
> 
> > > 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.
> 
> Well, what I mean is, atleast for now, I need some kind of AVI demuxer... 
> finding B frames in an AVI is impossible without understanding the codec 
> and reading the packets, right?... I want to save that complexity for now 
> for atleast doing testing on my muxer...

i strongly recomand that you use a existing AVI demuxer, lavf, mpdemux, 
xine, whatever
reinventing this _will_ fail (you would have to write a framer layer too
for example)

[...]
-- 
Michael