[NUT-devel] Issues

[Oded Shimon]

The controversies so far...

1. checksum in frame headers/syncpoints
I did very much like the elegance with the syncpoints, however I did not 
like the hacks in code to accomplish this (frame header parser in 
find_syncpoint, put_frame using put_syncpoint to a temporary buffer, 
demuxing frame header is dependant of "saw syncpoint" context).
So I have no strong feelings either way with this. I do have a small 
proposal for overhead reduction in new method (if it's stupid say so and 
I'll drop it) - has_checksum being implicit by the rules it is manditory 
for - so you can save frame codes or a byte for coded flags... Come to 
think of it, the frame header for a frame that needs has_checksum is large 
already anyway...


2. limiting max_distance, max_frame_size
I say, keep them VLC, but add a MUST in spec regarding their value... Using 
'u(16)' is as silly as using it for the 'tmp_mul' vars in the main header 
which also have a MUST restriction...


3. prefix/compression for frames
Not sure if this is an actual controversy, possibly the flamewar going on 
has nothing to do with this (let's keep mplayer g5926 flames for another 
mailing list :).

I'm quite against the prefix stuff, for a completely other reason - it's a 
silly complexity for something that does not belong in the container. If 
you're gonna do this, you might as well compress the frames with bzip2 
while you're at it. underhead is nice, but not that nice, this will be 
nothing but a legacy feature in the future...


4. Info frames/streams/packets
The first problem: limiting positions where info frames/packets should be
Michael you said you're strongly against this, but you also said a muxer 
should place them sanely and the demuxer should not go crazy looking for 
them. IMO there should be rules that you can't just put the frames/packets 
all over the place as you please, and I'd like to find the best ones that 
stay fully featured while still allowing the demuxer to not have to search 
everywhere for them.

Second problem: dump info streams?
There is some advantage to this - info frames don't really have stream like 
behavior, unless you repeat them often. A NUT-aware streaming server could 
give the info frame relavent to current position just once, and not be 
wasteful and repeat often or at all... Info streams can work if you put an 
EOR closely after the frame, but that is not semantically correct...
What I hate about dumping info streams though is some complication to my 
demuxer api (each call can give a frame or a packet, instead of always a 
frame), and, if we do dump info streams, I very much want a restriction 
that info packets that are global (chapter_id >=0 ?) can only come after 
main headers, and not wherever...

Thinking again about my streaming example, the file isn't seekable anyway, 
and if you dump it, and you're still using the info frames instead of 
remuxing them to info packets, you deserve what you get of an 
unseekable/bad seekable file... (Which would nicely discourage using info 
frames in places where it is inappropiatte - not live streams..)

- ods15