Re:

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 <daliasaerifal.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
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Wednesday 20 February 2008 18:01:31 Måns Rullgård
wrote:

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

but golomb coding is much heavier to decode than vlc,
and considering that the CPU has to waste a lot of time
decoding video and audio it seems a real waste of resources
to me, 
especially considering the minimal advantages it takes and
the
added complexity it requires in a demuxer

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Wed, Feb 20, 2008 at 05:01:31PM -0000, Måns Rullgård
wrote:
> > 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.

The only fields that make any difference to overhead are in
syncpoints
and frame headers. If 3 bits are really sufficient for one
of these
fields, then the framecode will do a perfectly nice job
without nasty
computational overhead.

> Grouping unrelated elements
> into a single vlc value to get around this
inefficiency, strikes me as
> hackish.

Do you mean framecodes? Or flags-style fields? In either
case, it's
pragmatic; in the case of flags it's standard practice.

In any case the time for this discussion is long past, by 5+
years..

Rich
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel