[NUT-devel] Issues

[Oded Shimon]

On Fri, Mar 03, 2006 at 07:21:08PM +0100, Michael Niedermayer wrote:
> 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

I still intend to have the flag... Just automatically set it on

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

No objection

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

Everybody will use Snow! :P

Saddens me that they still haven't been obsoleted...

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

Yeah I said myself, it's just not right.

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

I'm somewhat confused by that statement.. You mean, you don't mind a rule 
"all info packets must come after main headers", but against "all info 
packets with X must come after main headers".

Well, OK, how do you feel about:
all info packets must come after main headers
all info frames must be hapter_id < 0

And...
all info frames must have chapter_start<=pts<=chapter_end .


I think these are all the restrictions I'm interested in.

- ods15