[NUT-devel] Codec id - random notes

[Luca Barbato]

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
architectures.
(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.

right.

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

lu

-- 

Luca Barbato

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