[NUT-devel] Codec id - random notes
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
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
- 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
> 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)
- each byte from ascii if possible
- one tag per codec format regardless the type (audio,video,subs,meta)
- a black/blue night paint
More information about the NUT-devel