Codec id - random notes

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.

lu


-- 

Luca Barbato

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

2006/6/21, Luca Barbato <lu_zerogentoo.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.
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Hi

On Wed, Jun 21, 2006 at 01:34:41AM +0200, Luca Barbato
wrote:
[...]
> a- what about workarounds you need to apply for certain
encoders?
> - usually such hints could be guessed from the stream
itself.

there are some rare case where this is not true and the
fourcc is needed
for playback (XVIX (xvid + some interacing bug) for example)


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

irrelevant, this just doesnt work in reality, you need to
play streams
droping support for a few rare fourcc dependant workarounds
is one thing
dropping support for all not standard compliant streams is
just not
feasable


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

you mean fourcc in the info packet? (somehow this is just
shifting
things around not really changing anything) also info
packets are
supposed to be optional but here the fourcc field might be
needed
for the codec workarounds...

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or
copy any book
Today you'd get arrested for mere telling someone where the
library is
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu

http://lists.mplayerhq.hu/mailman/listinfo/nut-devel