[NUT-devel] Another suggestion for broadcast [PATCH]

[Rich Felker]

On Wed, Feb 20, 2008 at 03:25:37PM -0000, Måns Rullgård wrote:
> 
> Michael Niedermayer wrote:
> > On Wed, Feb 20, 2008 at 09:32:48AM +0000, Måns Rullgård wrote:
> >> Rich Felker <dalias at aerifal.cx> writes:
> >>
> >> > On Wed, Feb 20, 2008 at 01:32:14AM +0000, Måns Rullgård wrote:
> >> >> Another possibility is to precede each optional field with a 1-bit
> >> >> flag indicating its presence.  The size of the containing element can
> >> >> then also implicitly exclude any unused fields at the end.  This may
> >> >> of course not be desired for frequently repeated elements where the
> >> >> flags could be specified in a global header.
> >> >
> >> > I hope you understand, a 1bit field means a 1byte field. NUT has no
> >> > support for sub-byte data units except when they're appropriately
> >> > padded with reserved bits.
> >>
> >> Sounds like a deficiency.
> >
> > In what respect? That is what would we gain with droping byte alignment?
> > I think we would gain a lot of complexity primarely ;)
> 
> I thought Nut was supposed to have minimal overhead.  Requiring a syntax
> element to use 8 bits, even if it doesn't need them is not minimal.
> 
> If you're willing to sacrifice a few bits for reduced complexity, that's
> fine.  I merely had the, apparently incorrect, impression that Nut was
> trying very hard to remove any unnecessary overhead, even in the text
> of the format specification ;-)

In order for vlc to be efficient for numbers in the ranges of sanity,
you need to use units larger than bits. It would be a huge waste to
have a continuation bit corresponding to each data bit. One
continuation bit for every 7 data bits works well in practice.

Essentially all fields in nut are vlc, so worrying about non-vlc
types' efficiency is really pointless.

Rich