[NUT-devel] Codec id - random notes

[Ivan Kalvachev]

2006/6/30, Rich Felker <dalias at aerifal.cx>:
> On Thu, Jun 29, 2006 at 11:14:23AM +0200, Michael Niedermayer wrote:
> > Hi
> >
> > On Thu, Jun 29, 2006 at 09:47:05AM +0300, Ivan Kalvachev wrote:
> > [...]
> > >
> > > So if there is no sane system we should at least _try_ to invent one.
> >
> > we? you want it, you would have to do all the work and maintain it until
> > you find someone else to take over maintainership
> >
> > until now noone has done any work toward a new id system so for me the
> > case is closed, the system will be avi-fourcc based, if you want something
> > else you can still invent and propose another system
>
> before proposing another system please tell us what specific concrete
> problems will result from using avi-style fourcc.
>
> > noone will promisse that any of it will be used, decissions are made
> > on technical terms, that was always the case
>
> i'd still like to see any attempt at explaining how a new naming
> system can have a technical advantage.
>
> > when i, oded or rich suggested something and it turned out bad it was
> > discarded too
>
> not necessarily bad, sometimes just impractical/infeasible.

--
a-avi system.
Use all avi tags  1:1.
- avi audio doesn't have 4cc, but 2 byte codes (wav-2bc). Some formats
doesn't even have them (that's why you can set them manually in
ffmpeg/mplayer).
- some formats have multiple fourcc. We need to either support them
all (a-avi) or create&maintain our own list (i-avi). Both approach
reqiure some kind of table and maintenance.
- player not aware of avi-4cc would need avi table/support.

--
Other a-* systems, more particularly a-mov have already been
eliminated by Michael. Strangely matroska people seem to prefer it.

--
b-A system.
Addopt selected 4cc from many different systems. Mainly avi & mov. It
was actually proposed to commit in nut.
- players that don't support both avi or mov would need mapping table.
- we have to maintain table.
- there is no way to prevent other from turning it into "b" only
system by using a-avi and a-mov fourcc.

--
AA system. I split it on 2 other systems,
--
random-AA
Include multiple tags for one format, hoping the demuxer would
recognize one of it.
e.g. converting file and leaving its original tags
(4cc,2bc,uuid,mkv-id,etc..) intact or including few other known
aliases.
- playable only from players that know these tags&aliases. (e.g. qt
won't player avi-xvid).
- no way to predict what tags the players will know.
- many redundant tags.

--
a-AA system
Require all know tags to be included for every stream.
- need to maintain table.
- many more redundant tags for every stream.

--
IAA system.
Include our "I" tag and some of know AA tags.
When transcoding
- need to maintain table

We don't have to include all know tags if player supports the "I"
table. Player could omit the table and relay only on AA tags, this way
reducing to original non-nut format behaviour (may or may not know the
fourcc).


Thoughts:

My original proposition was about AA system. I think that it is
mandatory whatever system we accept, it have to be kind of AA. It
guarantees that converted files would still be playable on players
that were able to play them before conversion.

AA systems needs to be variable size. 2bc, 4cc, uuid, mkv - all have
different sizes.

We can start with AA system and later then make it IAA.
Or have mandatory "I" system.

p.s.
I'm sure we could drive in curcles for very long time.
We need some goals for the tag system.