[NUT-devel] Codec id - random notes

Luca Barbato lu_zero at gentoo.org
Thu Jun 22 00:31:40 CEST 2006

Ivan Kalvachev wrote:
> That's exacly what we shouldn't do. We should either take it all or
> not take it at all.

No the 1:1 mapping is what we want.

> That's true only for the players that already support the chosen tag
> system.

We don't care about players that much we are JUST at container level.

> There is no need of hash list and other cruft. Anyway most of the new
> formats (wmv,mkv) have tags bigger than 32bits, so these players have
> to addapt anyway.

We won't care about it

> Comparing string is only 2 times slower that comparing fourcc, because
> string require loading of one pointer. You don't have to compare the
> whole string to find that it doesn't match;)

you just need a tag that match to your internal tags for codecs and then
feed the stream to the supposed codec...

> If speed is our god we could speed it up 2 times by using 16bit tag.

False, on x86 till 32bit/64bit it's all the same, on ppc either 64 or
128 it's all the same, similar reasoning for other noncrippled
(ok on pic that could be meaningful)

>> 4 why not taking JUST one previous tag system then?
>> - most of them aren't bijective
> I hear Rich's voice here (he is mathematician).

It's my voice. 1:1 constraint is from me and makes sense.

> This statement needs clarification (as about what kind of sets are we
> talking about).
> If we talk about tags then the proposed system is only surjective.

thats why I said that we need to have a subset of it.

> And what do you mean by "most" is there one that is bijective. Which one?

none to my knowledge.

>> 5 why just alphanumeric/Ascii for the tags?
>> - already present in the established systems
> This doesn't answer the question "why".
> Why they establish it in the other systems?

- stupid tools could deliver a meaningful information w/out having a
conversion table.
- human readable is good, always

> Summary: quicktime system is perfect and we must adopt it. As it is
> perfect, there is nothing to remove.

qt tags is surjective at best.

> There is no standard for these hits. Every encoder uses its own way.
> Hints of one decoder would be meaningless for the other.

that's why I wrote that you can put them on the info packet if you
really want to.

> However if we know the codec that had created this stream we could use
> the same codec to decode it and it would know these hits for sure.

standard encoders should not have to put hints in order to have the file
correctly decoded.

> One of the problems with decoders is that they need to parse some
> stream data before they find these hints. This is problem for
> streaming applications where we would need to seek back in case we
> want another decoder. (note that hints here is true both for profile
> and encoder)

the I/O isn't our concern

> Shit happens. None of these bugs are intensional. Some are just edge
> cases of the standard (e.g. empty vop from xvid).
> You can't fix the past. (some people still try, thought;)

so you may have the hints in the info packets, lesser player may need
them, good player won't have to read them.

>> - they could be replicated in the info packet w/out many issues.

> We are not in position to force anything. We could just register know
> tags. Wiki would work just fine.

wiki has already a page about it.

> However we should (try to) create system that is self explanationary
> and self maintainable.


> I'm waiting.

haven't slept enough

> I have one request.
> I'd be happy if we forget for a while that there are other existing
> tag systems and try to implement our own.

the wiki is available,
for me the pure tag system would be:

- up to commonly used register dimension across arches (32bit for now)
in size
- each byte from ascii if possible
- one tag per codec format regardless the type (audio,video,subs,meta)
- ...
- a black/blue night paint



Luca Barbato

Gentoo/linux Gentoo/PPC

More information about the NUT-devel mailing list