[NUT-devel] Codec id - random notes

[Ivan Kalvachev]

2006/6/21, Luca Barbato <lu_zero at gentoo.org>:
>
> 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.

That was rithorical question :)

> 2 why 32bit?
> - It's a nice number for the cpu.
> - enough space for now

That's never been an issue. 16bits are also enough for all current formats :)

> - we can just take another 32bit tag system and reduce to our needs, so

That's exacly what we shouldn't do. We should either take it all or
not take it at all.

> current players won't have to convert to their internal presentation in
> complex ways (hash lists, multicolum lookups, whatever).

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

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.

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

As I had pointed out the table is not very big so we don't really need
mysql or oracle to hold the tags.


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


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

The question is good, but the answer is not good enough.
What are these errors?

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

I hear Dick's voice here (he is mathematician).
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.

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

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

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

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

> Side notes:
>
> a- what about workarounds you need to apply for certain encoders?
> - usually such hints could be guessed from the stream itself.

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

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.

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)

> - a proper decoder should conform to the standard completely and not
> need hints

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

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

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

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

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

I'm waiting.


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.