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

[Måns Rullgård]

Rich Felker wrote:
> 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.

The optimal coding of a field depends on the distribution of values,
not only on the valid range.  For instance, if the value is very small,
say 0--2, in 99% of all cases, but is occasionally much higher, other
schemes become attractive.  A simple one is the exp-golomb coding
used in H.264.  I assume you hate it, if for no other reason because
it is used in an MPEG standard, but I mention it nonetheless (or
maybe because of this).

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

A Nut vlc value is at least 8 bits, which is wasteful if, say, 3 bits
are sufficient for a given syntax element.  Grouping unrelated elements
into a single vlc value to get around this inefficiency, strikes me as
hackish.

-- 
Måns Rullgård
mans at mansr.com