[NUT-devel] Issues

[Rich Felker]

On Fri, Mar 03, 2006 at 07:31:12PM +0200, Oded Shimon wrote:
> 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...

Hmm, making it implicit is a good idea. I like that because it avoids
wasting framecodes, although of course you could always just use a
single 'wasted framecode' for "everything coded explicitly" which
would probably be the most sane way to do huge frames.

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

Agree.

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

Agree. :)

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

I tend to agree, but I don't want to argue over this issue since it's
gotten totally off-topic and turned into flames about unrelated
things. It's up to you and Michael what to do with this.

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

Agree strongly. Michael, if you insist on having some type of info
packets that can be positioned at any random place in the file, I also
want there to be some way for the demuxer to know when the file author
was sane and only placed the packets where they belong. Info streams
with full stream semantics were my preferred solution, but I'm open to
other equivalent approaches. Things I don't want though:

- being required to transmit a duplicate info packet at the end of a
  chapter just to update the length.

- having to search the whole file to find the info that applies to a
  given time interval.

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

IMO this makes sense.

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

Agree; however it's not that bad.

Rich