[NUT-devel] Issues

[Michael Niedermayer]

Hi

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

iam weakly against the implicit checksum without a flag, why:
* if by whatever reason a past timestamp is messed up the implicit rule
  would be messed up too
* no way to add extra checksums if theres no flag


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

well, iam certainly in favor of MUST restrictions on these values though i
would prefer choosing a type which makes it impossible to violate the
restriction
maybe saying that a (de)muxer MUST treat a value outside the 1...x range as x
would be a compromise


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

you think all the new stuff the standard comitees will produce wont
have redundant startcodes?


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

ok


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

iam strongly against EOR tricks ...



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

i have no strong oppinion on mainheader-infopacket relative ordering as long
as it doesnt depend on info packet contents


[...]
-- 
Michael