[NUT-devel] Codec id - random notes

Luca Barbato lu_zero at gentoo.org
Wed Jun 21 01:34:41 CEST 2006

0 a player (sane) has a physical stream layer (I/O), a demuxer layer,
upper layers till the users. We are discussing about a container so we
should care about that happened at the demuxer layer, nothing more higher.

1 why we need codec id (tag) and we cannot just go tagless and let the
decoders try to parse the stream and tell if they can decode it or not?
- Raw formats
- takes much more time
- Isn't something the container level should do, players willing to play
guess games can just ignoring the proposed tag.
- the player could just use the tag, lookup which codec could fit and
play it.

2 why 32bit?
- It's a nice number for the cpu.
- enough space for now
- we can just take another 32bit tag system and reduce to our needs, so
current players won't have to convert to their internal presentation in
complex ways (hash lists, multicolum lookups, whatever).

3 why not a fixed field?
- 640k are enough for everybody (learn for other people errors)

4 why not taking JUST one previous tag system then?
- most of them aren't bijective

5 why just alphanumeric/Ascii for the tags?
- already present in the established systems

summary: we could restrict our field to "just" 32bit for now since suits
our needs, we just take quicktime ids and clean them up so we have just
a 1:1 mappings.

Side notes:

a- what about workarounds you need to apply for certain encoders?
- usually such hints could be guessed from the stream itself.
- a proper decoder should conform to the standard completely and not
need hints
- they could be replicated in the info packet w/out many issues.

b- what about new codecs/formats?
- we provide some guidelines about new tags
- we provide a lint tool to spot files breaking such guidelines.
- new tags will be accepted either by webform or ml submission if the
codec developers want the format officially supported before nut devels
will notice themselves an add it to the list.
- non official stuff won't be nut compliant.

That's all for now, more structured reasoning will appear once I've
slept enough.



Luca Barbato

Gentoo/linux Gentoo/PPC

More information about the NUT-devel mailing list