Re:

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 

-- 
Måns Rullgård
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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.

True, but it simplifies things alot. Especially with byte
aligned frame data.

Also about overhead nut can for example store VBR mp3 with
single byte frame
headers, and at the same time removing 4 bytes from the mp3
frames, thats 
-3 bytes overhead. (We dont have an implemetation capable of
muxing this yet
though)

This actually might make it advantaneous to store mp3 in nut
instead of raw
mp3, and even more so as one could accurately seek in the
nut file.



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

Yes, theres no sense in saying something more than once 

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? --
Diogenes of Sinope

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

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.

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

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