[NUT-devel] Issues

[Michael Niedermayer]

Hi

On Fri, Mar 03, 2006 at 08:43:50PM +0200, Oded Shimon wrote:
> 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

so a frame which has checksum=no will be legal and have a checksum?
iam strongly against this, either no flag or a flag but not such a
hack


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

commited


[...]
> > > 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".

yes


> 
> Well, OK, how do you feel about:
> all info packets must come after main headers

iam very slightly against this but i dont really care


> all info frames must be hapter_id < 0
> 
> And...
> all info frames must have chapter_start<=pts<=chapter_end .

is there anything info frames can what info packets cant? if no
then i dont care about how info frames are restricted as i would
simply choose not to use them
otherwise i very strongly object against both

[...]
-- 
Michael