codec id nonsense, please end it

we were on the verge of finishing nut entirely when this
whole
flamewar started and i'd like to see it end. while i agree
with ivan's
sentiment that we do not want the huge mess of random
nonsensical
fourcc's creeping into nut, i'm also quite confident that
ivan's
proposal will not solve the problems he claims it will. as
long as a
"new style" codec id is required (and if it's
not required it's
useless and stupid like matroska's dual system) then
whenever users
want to use a codec that's not in the official list
they'll just copy
a random fourcc or other string to use as the codec
identifier.

on the other hand, the disadvantages of making a new codec
id system
are significant. most importantly, it requires every player
that wants
to support nut to either switch to using the new codec id
system
(nut-centric) and map all old fourcc's from other
containers to the
new system, or to map all nut codec ids to fourccs. both of
these
procedures require pointless large conversion tables.

while the fourcc situation historically is ugly, the
proposal i've
been mostly agreeing with (i don't call it mine because
iirc it was
put together from the ideas of many people) seems the best
to remedy
the situation. like all legitimate standardization processes
in which
the party making the standard is providing rules whose
influence
extend outside their scope, our process for standardizing
codec ids
should:

1. abstract common characteristics of historical
implementations

2. eliminate characteristics which are vendor-specific
and/or provide
   duplicate or ambiguous functionality

3. only as a last resort, fill in new definitions where
steps 1 and 2
   have left any gaps.

in our case, this means looking at existing fourcc values
and other
fourcc-compatible codec identifiers used in avi, quicktime,
nsv, etc.
and choosing among them the ones which are sane
(human-readable and
vendor-neutral). this resulted in a list like
"mp4v", "mp3 ", "h264",
"mpg1", ...

the benefit of using existing fourcc's is significant
because any
multi-format player can lookup a working decoder for a
stream with its
existing fourcc->decoder tables rather than requiring a
whole new set
of tables. while designing a new codec id system could be
useful, it
is beyond the scope of a container format simply because of
big-O
considerations. if each universal (any-codec) container has
its own
nonsense codec id system, then the size of the tables grows
as
O(num_containers*num_codecs) instead of just O(num_codecs).

i do not object at all to commenting in the nut spec that,
in the
event of a new future codec id standard that's
well-designed, a future
nut version may support using the new id system instead of
fourcc.
however, making a new codec id system and getting all
containers to
adopt it is WAAAY to ambitious of a project right now and
WAAAAY
outside the scope of what nut is trying to do.

as for ivan's concern that lamers will just use crap
fourccs (like
DIVX, XVID, X264, ...) instead of the correct/standardized
ones, there
are lots of other things lamers can do too, and nutlint
and/or the
reference demuxer should warn about or discourage their
stupidity.
actually i would like to see a list of "illegal
fourccs" in the
reference muxer so it knows all the classic
vendor-specific/ambiguous
fourccs and rejects them as permenantly invalid. this would
be a
fairly small table, just 4 bytes per fourcc.

other ideas welcome, but i really hope we can put this issue
aside
asap and get on with release..

rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Rich Felker <daliasaerifal.cx> writes:

> on the other hand, the disadvantages of making a new
codec id system
> are significant. most importantly, it requires every
player that wants
> to support nut to either switch to using the new codec
id system
> (nut-centric) and map all old fourcc's from other
containers to the
> new system, or to map all nut codec ids to fourccs.
both of these
> procedures require pointless large conversion tables.

There is *nothing* universal about so-called fourccs.  They
just
happen to be used by AVI, and AVI is unfortunately the most
wide-spread format.  Quicktime also uses 32-bit codes, but
they are
*different* from those used in AVI for many codecs.  It is
most
obvious for audio, where quicktime uses four printable
chars, as for
video, while AVI uses a 16-bit number.

Any player capable of playing more than one file format will
need
tables to convert from whatever the input files use to
something
internal, whether or not the internal codes are equal to
those used by
one format or another.

> while the fourcc situation historically is ugly, the
proposal i've
> been mostly agreeing with (i don't call it mine
because iirc it was
> put together from the ideas of many people) seems the
best to remedy
> the situation. like all legitimate standardization
processes in which
> the party making the standard is providing rules whose
influence
> extend outside their scope, our process for
standardizing codec ids
> should:
>
> 1. abstract common characteristics of historical
implementations
>
> 2. eliminate characteristics which are vendor-specific
and/or provide
>    duplicate or ambiguous functionality
>
> 3. only as a last resort, fill in new definitions where
steps 1 and 2
>    have left any gaps.
>
> in our case, this means looking at existing fourcc
values and other
> fourcc-compatible codec identifiers used in avi,
quicktime, nsv, etc.
> and choosing among them the ones which are sane
(human-readable and
> vendor-neutral). this resulted in a list like
"mp4v", "mp3 ", "h264",
> "mpg1", ...
>
> the benefit of using existing fourcc's is significant
because any
> multi-format player can lookup a working decoder for a
stream with its
> existing fourcc->decoder tables rather than
requiring a whole new set
> of tables. while designing a new codec id system could
be useful, it
> is beyond the scope of a container format simply
because of big-O
> considerations. if each universal (any-codec) container
has its own
> nonsense codec id system, then the size of the tables
grows as
> O(num_containers*num_codecs) instead of just
O(num_codecs).

That is *already* the case.

> i do not object at all to commenting in the nut spec
that, in the
> event of a new future codec id standard that's
well-designed, a future
> nut version may support using the new id system instead
of fourcc.

To that end, it makes sense making the field syntactically
variable-sized.  If a player wants to treat 4-byte
identifiers as a
number, it may do so now.  If a later standard uses longer
identifiers, such players will have to change, but they will
need
updating anyway if the codec identifications change.

-- 
Måns Rullgård
mruinprovide.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Rich Felker wrote:
[postpone discussion later, just complete version 1 now,
fourcc is the
simplest solution.]

Ok, looks sane that way, BUT

[O(), tables, complexity, nobody will use our codecs]

No, having a codec table for nut isn't any different than
what we have
already (see ogg, qt/mov, avi, mkv). So I'd like to have
what iive
proposed for the next nut revision and that means that the
fourcc field
should be changed now as codec_id and it should stay vb.
The next revision will add the options about
encoder/producer and so on.

I know that doesn't sound fine, but

- somebody will bitch about complexity and bloat while it
doesn't matter
at all and a month is needed to convince them to move from
their
position (from past experience)

- avi fourcc and mov aren't that nice about tags as the
proposed long
term solution.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/
~lu_zero

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

2006/6/20, Rich Felker <daliasaerifal.cx>:
> we were on the verge of finishing nut entirely when
this whole
> flamewar started and i'd like to see it end. while i
agree with ivan's
> sentiment that we do not want the huge mess of random
nonsensical
> fourcc's creeping into nut, i'm also quite confident
that ivan's
> proposal will not solve the problems he claims it will.
as long as a
> "new style" codec id is required (and if
it's not required it's
> useless and stupid like matroska's dual system) then
whenever users
> want to use a codec that's not in the official list
they'll just copy
> a random fourcc or other string to use as the codec
identifier.

It's not user job to create format_id, it is codec
maintainer person.
Users changing fourcc is part of the problem.

> on the other hand, the disadvantages of making a new
codec id system
> are significant. most importantly, it requires every
player that wants
> to support nut to either switch to using the new codec
id system
> (nut-centric) and map all old fourcc's from other
containers to the
> new system, or to map all nut codec ids to fourccs.
both of these
> procedures require pointless large conversion tables.

I don't have problem with world domination.

I'm sick of this mythical table nonsense.
There is ALWAYS a table.

It could be distributed - each codec/module/demuxer knows
fourcc it
can play and how to map them  (ffmpeg?)

It could be centralized - one table that contains all
codecs. It is
like codecs.conf in mplayer that atm is 56k big in source
(text) form.
 This is the biggest known table mapping of all possible
fourcc to all
possible codecs. (it's 14kb gzip-ed).

A player that support more than one format - avi ,wmv,
mov/qt. mkv
does need some kind of table for interoperability, adding
few new
entries is not huge issue.

Should I remind you that current proposal is mixture of avi
and qt ?
This means that if player supports only one of these we
still need
special mapping table, no matter how compatible codecs
we've chosen.

So tables are unavoidable. And even doubling the size of the
biggest
know would not make more than 32kb....


> while the fourcc situation historically is ugly, the
proposal i've
> been mostly agreeing with (i don't call it mine
because iirc it was
> put together from the ideas of many people) seems the
best to remedy
> the situation. like all legitimate standardization
processes in which
> the party making the standard is providing rules whose
influence
> extend outside their scope, our process for
standardizing codec ids
> should:
>
> 1. abstract common characteristics of historical
implementations
>
> 2. eliminate characteristics which are vendor-specific
and/or provide
>    duplicate or ambiguous functionality
>
> 3. only as a last resort, fill in new definitions where
steps 1 and 2
>    have left any gaps.
>
> in our case, this means looking at existing fourcc
values and other
> fourcc-compatible codec identifiers used in avi,
quicktime, nsv, etc.
> and choosing among them the ones which are sane
(human-readable and
> vendor-neutral). this resulted in a list like
"mp4v", "mp3 ", "h264",
> "mpg1", ...

I'm happy we haven't created nut using this method.

> the benefit of using existing fourcc's is significant
because any
> multi-format player can lookup a working decoder for a
stream with its
> existing fourcc->decoder tables rather than
requiring a whole new set
> of tables. while designing a new codec id system could
be useful, it
> is beyond the scope of a container format simply
because of big-O
> considerations. if each universal (any-codec) container
has its own
> nonsense codec id system, then the size of the tables
grows as
> O(num_containers*num_codecs) instead of just
O(num_codecs).
>
> i do not object at all to commenting in the nut spec
that, in the
> event of a new future codec id standard that's
well-designed, a future
> nut version may support using the new id system instead
of fourcc.
> however, making a new codec id system and getting all
containers to
> adopt it is WAAAY to ambitious of a project right now
and WAAAAY
> outside the scope of what nut is trying to do.

Why don't you give it a shot?

A new codec_id standard cannot come out of thin air,
somebody must
invent it, implement it and use it.

Nut have the potential to make a difference.

If you had put at least half of the effort you made for
backward_ptr
in developing new format_id system, NUT would have been
compleated
already.

> as for ivan's concern that lamers will just use crap
fourccs (like
> DIVX, XVID, X264, ...) instead of the
correct/standardized ones, there
> are lots of other things lamers can do too, and nutlint
and/or the
> reference demuxer should warn about or discourage their
stupidity.
> actually i would like to see a list of "illegal
fourccs" in the
> reference muxer so it knows all the classic
vendor-specific/ambiguous
> fourccs and rejects them as permenantly invalid. this
would be a
> fairly small table, just 4 bytes per fourcc.

 ((2^32) - number_of_legetime_fourcc)*4

>
> other ideas welcome, but i really hope we can put this
issue aside
> asap and get on with release..

I know one thing. If I neglect something, it will come to
bite me at
later point.

NUT is well polished format. Every aspect have been flamed,
hammered,
tuned and tempered.
I don't want to neglect the probably most important at user
point of
view aspect because you are hurrying for the release.
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Ivan Kalvachev wrote:

> NUT is well polished format. Every aspect have been
flamed, hammered,
> tuned and tempered.
> I don't want to neglect the probably most important at
user point of
> view aspect because you are hurrying for the release.

Do you have the time to add a little proof of concept using
libnut and
mplayer?

Sticking to the current situation could help finding issues.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/
~lu_zero

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Tue, Jun 20, 2006 at 08:22:03PM +0100, Måns Rullgård
wrote:
> Rich Felker <daliasaerifal.cx> writes:
> 
> > on the other hand, the disadvantages of making a
new codec id system
> > are significant. most importantly, it requires
every player that wants
> > to support nut to either switch to using the new
codec id system
> > (nut-centric) and map all old fourcc's from other
containers to the
> > new system, or to map all nut codec ids to
fourccs. both of these
> > procedures require pointless large conversion
tables.
> 
> There is *nothing* universal about so-called fourccs. 
They just
> happen to be used by AVI, and AVI is unfortunately the
most
> wide-spread format.  Quicktime also uses 32-bit codes,
but they are
> *different* from those used in AVI for many codecs.  It
is most
> obvious for audio, where quicktime uses four printable
chars, as for
> video, while AVI uses a 16-bit number.
> 
> Any player capable of playing more than one file format
will need
> tables to convert from whatever the input files use to
something
> internal, whether or not the internal codes are equal
to those used by
> one format or another.

This is incorrect. The quicktime, avi, and other id numbers
do not
overlap, so no table of conversions is needed. All that's
needed is a
list of 32bit ids mapping to decoders, and this list can be
shared
among all formats.

If you had bothered to read the earlier threads this was
already
addressed.

> > the benefit of using existing fourcc's is
significant because any
> > multi-format player can lookup a working decoder
for a stream with its
> > existing fourcc->decoder tables rather than
requiring a whole new set
> > of tables. while designing a new codec id system
could be useful, it
> > is beyond the scope of a container format simply
because of big-O
> > considerations. if each universal (any-codec)
container has its own
> > nonsense codec id system, then the size of the
tables grows as
> > O(num_containers*num_codecs) instead of just
O(num_codecs).
> 
> That is *already* the case.

No it's not.

> > i do not object at all to commenting in the nut
spec that, in the
> > event of a new future codec id standard that's
well-designed, a future
> > nut version may support using the new id system
instead of fourcc.
> 
> To that end, it makes sense making the field
syntactically
> variable-sized.

Absolutely everything in NUT is syntactically
variable-sized, except
the index pointer at EOF which would just be difficult to
parse if it
were. The question is not of syntax and never has been. The
question
is semantics.

> If a player wants to treat 4-byte identifiers as a
> number, it may do so now.  If a later standard uses
longer
> identifiers, such players will have to change, but they
will need
> updating anyway if the codec identifications change.

Yes, with the added stipulations that, currently,
identifiers are
required (semantically, not syntactically) to be 4-byte, and
that
existing identifiers are reused whenever possible to avoid
senselessly
bloating up the table or clashing with existing table
entries from
other container formats.

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Tue, Jun 20, 2006 at 10:10:30PM +0200, Luca Barbato
wrote:
> Rich Felker wrote:
> [postpone discussion later, just complete version 1
now, fourcc is the
> simplest solution.]
> 
> Ok, looks sane that way, BUT
> 
> [O(), tables, complexity, nobody will use our codecs]
> 
> No, having a codec table for nut isn't any different
than what we have
> already (see ogg, qt/mov, avi, mkv).

Yes it is. The only formats that need their own special
tables right
now are the ones with small restricted sets of codecs and
new specs
for each additional codec they support, i.e. ogg and mkv.
Everything
else uses a common list of fourcc-compatible identifiers.

> So I'd like to have what iive
> proposed for the next nut revision and that means that
the fourcc field
> should be changed now as codec_id and it should stay
vb.

Of course all fields will stay variable-length even if the
semantic
requirements demand a specific size. This has NEVER been
questioned.

> The next revision will add the options about
encoder/producer and so on.

This useless info can go in the info packet.

> I know that doesn't sound fine, but
> 
> - somebody will bitch about complexity and bloat while
it doesn't matter
> at all and a month is needed to convince them to move
from their
> position (from past experience)

More than that.

> - avi fourcc and mov aren't that nice about tags as
the proposed long
> term solution.

Yes they are. The more small/restricted the set of
identifiers is, the
less likely people are to make stupid
"equivalent" names. Consider for
example iso language codes versus ogg language crap.
"eng" is very
simple and standard and no one will make variants on it.
"English"
could easily become "english",
"eng", "English(US)", "English
with
some foreign words", "ENGLISH",
"eNgLiSh", etc.

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Tue, Jun 20, 2006 at 11:28:36PM +0300, Ivan Kalvachev
wrote:
> >i do not object at all to commenting in the nut
spec that, in the
> >event of a new future codec id standard that's
well-designed, a future
> >nut version may support using the new id system
instead of fourcc.
> >however, making a new codec id system and getting
all containers to
> >adopt it is WAAAY to ambitious of a project right
now and WAAAAY
> >outside the scope of what nut is trying to do.
> 
> Why don't you give it a shot?

Because it has no benefits. None of the problem of current
container
formats is due to fourcc. It's due to missing or incorrect
data about
the stored frames, inefficiency, lack of robustness, etc.

> If you had put at least half of the effort you made for
backward_ptr
> in developing new format_id system, NUT would have been
compleated
> already.

As far as I'm concerned NUT is completed already.

> NUT is well polished format. Every aspect have been
flamed, hammered,
> tuned and tempered.
> I don't want to neglect the probably most important at
user point of
> view aspect because you are hurrying for the release.

This is not an important point. Anyway... here let's use a
new codec
id system. In the new system all names will be exactly 4
characters,
and here are the first 6 entries:

mp4v - mpeg4 video
aac  - aac audio
mp3  - mp3 audio
mp2  - mp2 audio
h264 - h264 video
vrbs - voris audio

Any correspondence to historically used names from fourcc or
qt
identifier is purely coincidental. ))

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Hi,

> This is not an important point. Anyway... here let's
use a new codec
> id system. In the new system all names will be exactly
4 characters,
> and here are the first 6 entries:
> 
> mp4v - mpeg4 video
> aac  - aac audio
> mp3  - mp3 audio
> mp2  - mp2 audio

What about mp2a / mp3a? So mp2v could exist (and not mpg2).
Otoh aaca
would look crazy 

Also I would restrict the available character set from your
proposed
ascii-printable to alphanumeric+space, everything else is
making it more
complicated. The dash (-) is the only symbol I could be
convienced if
too much ppl cry.

-- 
Alex Beregszaszi	email: alexfsn.hu
Free Software Network	cell: +36 70 3144424
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Tue, Jun 20, 2006 at 11:39:41PM +0200, Alex Beregszaszi
wrote:
> Hi,
> 
> > This is not an important point. Anyway... here
let's use a new codec
> > id system. In the new system all names will be
exactly 4 characters,
> > and here are the first 6 entries:
> > 
> > mp4v - mpeg4 video
> > aac  - aac audio
> > mp3  - mp3 audio
> > mp2  - mp2 audio
> 
> What about mp2a / mp3a? So mp2v could exist (and not
mpg2). Otoh aaca
> would look crazy 

The idea was to use existing sane names when they exist to
avoid
pointlessly enlarging tables. Also mp2a and mp3a are NOT
analogous to
mp4v. mp2 does not mean mpeg-2 audio. It means mpeg-1 audio,
layer 2.
Similarly for mp3.

> Also I would restrict the available character set from
your proposed
> ascii-printable to alphanumeric+space, everything else
is making it more
> complicated. The dash (-) is the only symbol I could be
convienced if
> too much ppl cry.

Plus is also useful, e.g. 263+, mp3+, etc. crap. 

Rich

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel