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@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@mansr.com