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
2006/6/21, Luca Barbato <lu_zero@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.
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
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
Michael Niedermayer wrote:
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...
I meant hints for decoding properly not replicated fourcc. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Hi On Thu, Jun 22, 2006 at 01:08:14AM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
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...
I meant hints for decoding properly not replicated fourcc.
this is silly, the code to detect these things is in and belongs to the decoder, having several pages of code per codec in nut for this is just totally unrealistic not to mention that all that would need to be mapped back to fourccs before 98% of the codecs could make any sense of it so IMO, please first find a problem then think about a solution, not find a solution and then search for a problem fourccs work, there never was a problem with them which another id system wouldt have too so my vote is to use the avi fourccs and be done with it if you start remapping fourccs, ids whatever you introduce problems not solve any, divx,xvid,... -> mp4v might be philosophically correcter but it doesnt improve anything a completely new id system is not acceptable, in case the reader dissagrees he can do the work, proof it works (divx/xvid/...)fourcc based workarounds transcoding these streams back to avi and worarounds still working and so on [...] -- 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
Michael Niedermayer wrote: [avi way or highway] Not sure, I'd rather have a bitfield as hint in the info packet and just let advanced player and decoders know about it. I won't use avi just because the twocc for audio. Proponents of alternative systems consider them because they don't like the idea of cluttering the tag list with producer specific and nonstandard tags while you may archive the same result adding an optional field to explain what you should do. if $specific_encoder got to the point of being standard but retains the tag it used when wasn't standard at all what would happen to the decoder if you just store the information "format mp4v, encoded by xvid, workarounds A,B,C" as XVID? if you store it as tag = mp4v X-encoder= "xvid-$ver_pretty_sane" - players not caring could try to play it at their best and in this case have no problems. - players with a complete decoder will see the lack of hints and decode it properly - players particularly smart could also use the encoder string and pick the matching decoder if present. if you just store the tag as XVID - players will still try to play it as if the workarounds are necessary and maybe trigger workarounds that aren't meant to be used. - players not knowing about XVID will still either play the guess game or give up. On the other hand: - using different tags you deliver the information in a more compact (but more ambiguous) form - having hints and other metadata as described looks overengineering quite a bit and will require some work to support it properly (if we care just about lavc it isn't that hard, but...). Did I sum up Michael position and the previous ones correctly? lu - yes, I don't have strong opinions about it, I just want to have NUT out as soon as possible. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Hi On Thu, Jun 22, 2006 at 11:41:59AM +0200, Luca Barbato wrote:
Michael Niedermayer wrote: [avi way or highway]
Not sure, I'd rather have a bitfield as hint in the info packet and just let advanced player and decoders know about it.
this is not feasable and absolutely useless, the muxer has ZERO knowledge about what encoder workarounds are needed, you cannot fill this struct from hot air, the muxer would have to decode several frames to be able to just _guess_ if a bug like incorrect padding at the end of mpeg4 frames happens this is very codec specific stuff, it doesnt belong to the muxer layer please forget it! send a path to libnut and you will see its not feasable [...] -- 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
Michael Niedermayer wrote:
please forget it! send a path to libnut and you will see its not feasable
Well I believe you even if I'm missing why randomcodec_init(int workarounds) won't work the call would be something like codecs[tag].init(hints) Proponents of alternate solutions (iive, dalias) are still against taking a default tag system as is? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Hi On Fri, Jun 23, 2006 at 10:17:58PM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
please forget it! send a path to libnut and you will see its not feasable
Well I believe you even if I'm missing why
randomcodec_init(int workarounds) won't work
the call would be something like codecs[tag].init(hints)
i have not the faintest clue what you are talking about but storing workarund hints in nut would need you to solve the following 1. the muxer has a packet and some codec identifer (fourcc, string or other) next the muxer must find the workaround hints, this requires decoding several frames (the muxer needs at least a mpeg4 decoder and possible some parsers for various headers of other codecs are you suggesting that the nut muxer should decode frames? yes ? no ? if no then from where do you want to find these hints? the muxer has a bunch of "opaque" bytes which are an encoded video frame and a codec id, things like width and height ... 2. the demuxer passes the hints to the codec, no codec in existance can make any sense of such hints, they either can detect the buggy encoder and deal with it or they cant, if half of the info has been butchered (fourcc changed from xvid to mp4v) then chances are _slightly_ lower that the detecton will work, most of the time it will, but not always you can of coarse just store the fourcc either alone or in addition to another identifer, that of coarse will help the decoder but i wouldnt call that "hints" [...] -- 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
Michael Niedermayer wrote:
Hi
1. the muxer has a packet and some codec identifer (fourcc, string or other) next the muxer must find the workaround hints, this requires decoding several frames (the muxer needs at least a mpeg4 decoder and possible some parsers for various headers of other codecs
are you suggesting that the nut muxer should decode frames? yes ? no ?
dalias was suggesting that, iive was proposing to store the informations about decoding (workaround or hints) in a separate field.
if no then from where do you want to find these hints? the muxer has a bunch of "opaque" bytes which are an encoded video frame and a codec id, things like width and height ...
2. the demuxer passes the hints to the codec, no codec in existance can make any sense of such hints, they either can detect the buggy encoder and deal with it or they cant, if half of the info has been butchered (fourcc changed from xvid to mp4v) then chances are _slightly_ lower that the detecton will work, most of the time it will, but not always
I see
you can of coarse just store the fourcc either alone or in addition to another identifer, that of coarse will help the decoder but i wouldnt call that "hints"
My naive idea was just to put in the field proposed by iive the workaround_bugs content. On decode init you just have to take it and put it in the struct. I can see different issues in this approach (like being quite ffmpeg centric). Replicating the specific fourcc could be another possibility, and as you said it would just mean we are wasting 4 byte just for keeping things clean for not so technical reason. so far no other proponents contested Michael stance beside me... lu PS: I'm trying to force people analyzing others ideas making summary, if I'm wrong please tell, if you think I'm wasting time please agree in another way on a tag system. -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Sat, Jun 24, 2006 at 12:20:21AM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
Hi
1. the muxer has a packet and some codec identifer (fourcc, string or other) next the muxer must find the workaround hints, this requires decoding several frames (the muxer needs at least a mpeg4 decoder and possible some parsers for various headers of other codecs
are you suggesting that the nut muxer should decode frames? yes ? no ?
dalias was suggesting that,
i suggested no such thing, it's idiocy!! like michael said this has absolutely nothing to do with the container! rich
2006/6/24, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Fri, Jun 23, 2006 at 10:17:58PM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
please forget it! send a path to libnut and you will see its not feasable
Well I believe you even if I'm missing why
randomcodec_init(int workarounds) won't work
the call would be something like codecs[tag].init(hints)
i have not the faintest clue what you are talking about but storing workarund hints in nut would need you to solve the following 1. the muxer has a packet and some codec identifer (fourcc, string or other) next the muxer must find the workaround hints, this requires decoding several frames (the muxer needs at least a mpeg4 decoder and possible some parsers for various headers of other codecs
are you suggesting that the nut muxer should decode frames? yes ? no ? if no then from where do you want to find these hints? the muxer has a bunch of "opaque" bytes which are an encoded video frame and a codec id, things like width and height ...
2. the demuxer passes the hints to the codec, no codec in existance can make any sense of such hints, they either can detect the buggy encoder and deal with it or they cant, if half of the info has been butchered (fourcc changed from xvid to mp4v) then chances are _slightly_ lower that the detecton will work, most of the time it will, but not always
you can of coarse just store the fourcc either alone or in addition to another identifer, that of coarse will help the decoder but i wouldnt call that "hints"
XviD stores bitstream version id. It is just number that is increased every time and encoder bug that affects decoding is fixed. If you have this number you can set workaround for all bugs even before the first decoded frame. (I guess this is not available for the oldest xvid streams, but still...) We have the trend to use tags/4cc that are format specific only, without any codec information. If we have codec information a player could prefer to decode the content with the same codec. For sure it would be able to workaround its own bugs.
Hi On Sat, Jun 24, 2006 at 01:41:15AM +0300, Ivan Kalvachev wrote:
2006/6/24, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Fri, Jun 23, 2006 at 10:17:58PM +0200, Luca Barbato wrote:
Michael Niedermayer wrote:
please forget it! send a path to libnut and you will see its not
feasable
Well I believe you even if I'm missing why
randomcodec_init(int workarounds) won't work
the call would be something like codecs[tag].init(hints)
i have not the faintest clue what you are talking about but storing workarund hints in nut would need you to solve the following 1. the muxer has a packet and some codec identifer (fourcc, string or other) next the muxer must find the workaround hints, this requires decoding several frames (the muxer needs at least a mpeg4 decoder and possible some parsers for various headers of other codecs
are you suggesting that the nut muxer should decode frames? yes ? no ? if no then from where do you want to find these hints? the muxer has a bunch of "opaque" bytes which are an encoded video frame and a codec id, things like width and height ...
2. the demuxer passes the hints to the codec, no codec in existance can make any sense of such hints, they either can detect the buggy encoder and deal with it or they cant, if half of the info has been butchered (fourcc changed from xvid to mp4v) then chances are _slightly_ lower that the detecton will work, most of the time it will, but not always
you can of coarse just store the fourcc either alone or in addition to another identifer, that of coarse will help the decoder but i wouldnt call that "hints"
XviD stores bitstream version id. It is just number that is increased every time and encoder bug that affects decoding is fixed. If you have this number you can set workaround for all bugs even before the first decoded frame.
mostly
(I guess this is not available for the oldest xvid streams, but still...)
yes the issues here though are that 1. as you say it fails with very old xvid (do you propose to drop support for that?) 2. xvid will store a id of "DivX503b1393" if the "correct" options are set it will store a xvid id too so there should be no problem currently but still discarding potentially usefull information is a risky practice this btw also shows nicely that intentionally wrong information isnt fourcc specific but its a issue caused by idiot companies who design decoders hw or sw that play only videos from a specific encoder, either you set the wrong id or your video doesnt play 3. xvid + some interlaced bug (only detectable through fourcc XVIX) 4. bugs from encoders which arent xvid or divx UMP4 comes to mind here, or a common bug with the padding at the end of frames detected by analyzing several frame ends [...] -- 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
Hi On Sat, Jun 24, 2006 at 01:32:01AM +0200, Michael Niedermayer wrote: [...]
the issues here though are that 1. as you say it fails with very old xvid (do you propose to drop support for that?) 2. xvid will store a id of "DivX503b1393" if the "correct" options are set it will store a xvid id too so there should be no problem currently but still discarding potentially usefull information is a risky practice this btw also shows nicely that intentionally wrong information isnt fourcc specific but its a issue caused by idiot companies who design decoders hw or sw that play only videos from a specific encoder, either you set the wrong id or your video doesnt play 3. xvid + some interlaced bug (only detectable through fourcc XVIX) 4. bugs from encoders which arent xvid or divx UMP4 comes to mind here, or a common bug with the padding at the end of frames detected by analyzing several frame ends
so it seems that we have the following options either store fourcc as is or not store it as is, that could be a simplified fourcc or no fourcc at all note, iam ignoring non fourcc ids here, we could store them too or not it makes no differense here ... if a unchanged fourcc is not stored then a very small number of streams will not be decodeable correctly, that is 1. some old xvid and divx before they stored their encoder build num in the stream 2. ump4 if we map that to m4v/mp4v 3. xvid with the interlacing bug if we map XVIX to mp4v/m4v 2 and 3 can be solved by saying that ump4 and xvix are not mpeg4 but this wont work for old xvid & divx ... in principle iam fine with any id system as long as its realistic (=people proposing complex stuff for nut must demonstrate the feasability of it first by implementing it) i also dont really care about being able to store broken mp4 in nut but i wont agree to a system being accepted based on a lie that it will work with every stream ... so IMHO a id system must be able to achive the following, if it doesnt then IMHO its not worth considering 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg to nut and produce a valid and playable file 2. streamcopy every such file back to its source container and still have a valid and playable file [...] -- 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
On Sat, Jun 24, 2006 at 01:27:24PM +0200, Michael Niedermayer wrote:
so IMHO a id system must be able to achive the following, if it doesnt then IMHO its not worth considering 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg to nut and produce a valid and playable file
this is inherently impossible due to missing pts. you must have a decoder (or at least a parser) to streamcopy from avi. rich
Rich Felker <dalias@aerifal.cx> writes:
On Sat, Jun 24, 2006 at 01:27:24PM +0200, Michael Niedermayer wrote:
so IMHO a id system must be able to achive the following, if it doesnt then IMHO its not worth considering 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg to nut and produce a valid and playable file
this is inherently impossible due to missing pts. you must have a decoder (or at least a parser) to streamcopy from avi.
I consider pts != dts in avi broken. -- Måns Rullgård mru@inprovide.com
On Sat, Jun 24, 2006 at 02:20:26PM +0100, Måns Rullgård wrote:
Rich Felker <dalias@aerifal.cx> writes:
On Sat, Jun 24, 2006 at 01:27:24PM +0200, Michael Niedermayer wrote:
so IMHO a id system must be able to achive the following, if it doesnt then IMHO its not worth considering 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg to nut and produce a valid and playable file
this is inherently impossible due to missing pts. you must have a decoder (or at least a parser) to streamcopy from avi.
I consider pts != dts in avi broken.
OK, but B frames in mpeg PS files is not broken (at least according to ISO...), yet still needs a decoder/parser to figure out pts for every frame :) - ods15
Oded Shimon <ods15@ods15.dyndns.org> writes:
On Sat, Jun 24, 2006 at 02:20:26PM +0100, Måns Rullgård wrote:
Rich Felker <dalias@aerifal.cx> writes:
On Sat, Jun 24, 2006 at 01:27:24PM +0200, Michael Niedermayer wrote:
so IMHO a id system must be able to achive the following, if it doesnt then IMHO its not worth considering 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg to nut and produce a valid and playable file
this is inherently impossible due to missing pts. you must have a decoder (or at least a parser) to streamcopy from avi.
I consider pts != dts in avi broken.
OK, but B frames in mpeg PS files is not broken (at least according to ISO...), yet still needs a decoder/parser to figure out pts for every frame :)
You can get useful information from MPEG PS/TS without a decoder, but you get nothing whatsoever from AVI. MPEG PS/TS requires a frame to have either no timestamp at all (in which case they can be calculated by the decoder), only a PTS (which requires PTS == DTS), or both PTS and DTS (which may differ). With AVI you know nothing at all, which is what makes it troublesome. -- Måns Rullgård mru@inprovide.com
Hi On Sat, Jun 24, 2006 at 01:27:24PM +0200, Michael Niedermayer wrote: [...]
in principle iam fine with any id system as long as its realistic (=people proposing complex stuff for nut must demonstrate the feasability of it first by implementing it) i also dont really care about being able to store broken mp4 in nut but i wont agree to a system being accepted based on a lie that it will work with every stream ...
so IMHO a id system must be able to achive the following, if it doesnt then IMHO its not worth considering 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg to nut and produce a valid and playable file
of course the avi case needs pts=dts to be valid to begin with
2. streamcopy every such file back to its source container and still have a valid and playable file
if we want XXX->NUT->XXX to work with preserving the id then we could either A: allow any id to be used, so files converted from avi would contain a avi-4cc and from mov would have a mov-4cc I: make our own independant system which contains an id for every id in every other container (this could of course be done in 2 fields like format and implementation) IA: store our own id and a source format id if available AA: store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc... IAA:store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc and require a nut-id) AAA:store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc and require a AVI-4cc) if we dont care about XXX->NUT->XXX a: adopt a single existing id system like the one from avi or mov b: like a but remap a few ids we dont like due to philosophical reasons i: design our own indepenant system for per format ids (no implemtation id) A I IA AA IAA a-avi a-mov b i AAA supports old divx/xvid streams: X X X X X X X AVI->NUT->AVI wont change 4cc: X X X X X X X MOV->NUT->MOV wont change 4cc: X X X X X X X no table maintaince: X X X X x X decoder can use existing tables:X X X x X X X decoder needs single nut-table: X X X X X X X X encoder doesnt need to remap id:X X x so, nothing is perfect, we cant have everything ... here are a few personal comments AA vs. A both muxer and demuxer complexity are the same the only difference is that the muxer can store more ids if it knows them in AA, which might help the decoder if it doesnt know all id systems so IMHO we can drop A IA vs IAA if we already support multiple ids per file then allowing to store more then 2 doesnt seem like a big differnce and might be slightly better in some cases, so id say drop IA a-avi vs. a-mov there are more avi fourccs then mov fourccs so IMHO a-avi would be a better choice, theres also the old xvid/divx advantage, IIRC theres no distinction between the 2 in mov, so IMHO we can drop a-mov b vs. a-avi b is philsophical better at the cost of playability of a very small number of divx & xvid videos and it needs a little more maintainance so IMHO we can drop b in favor of a-avi i vs I if we are really building our own format id table then i guess a field more for the implemenattion wont hurt so IMHO drop i AA vs. AAA AA has a big problem, the nut file could use any id system, so this moves alot of complexity to the demuxer, so i belive its not controversical if i drop it in favor of some other system like AAA or another one which does the remaping at the muxer side whats left: I AAA IAA a-avi supports old divx/xvid streams: X X X X AVI->NUT->AVI wont change 4cc: X X X X MOV->NUT->MOV wont change 4cc: X X X no table maintaince: X X decoder can use existing tables: X x X decoder only needs single table:X X X X encoder doesnt need to remap id: alternative suggestions, and comments welcome, personally iam fine with all the options left (for I and IAA a volunteer would be needed to maintain a few tables) [...] -- 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
2006/6/27, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Sat, Jun 24, 2006 at 01:27:24PM +0200, Michael Niedermayer wrote: [...]
in principle iam fine with any id system as long as its realistic (=people proposing complex stuff for nut must demonstrate the feasability of it first by implementing it) i also dont really care about being able to store broken mp4 in nut but i wont agree to a system being accepted based on a lie that it will work with every stream ...
so IMHO a id system must be able to achive the following, if it doesnt then IMHO its not worth considering 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg to nut and produce a valid and playable file
of course the avi case needs pts=dts to be valid to begin with
2. streamcopy every such file back to its source container and still have a valid and playable file
if we want XXX->NUT->XXX to work with preserving the id then we could either
A: allow any id to be used, so files converted from avi would contain a avi-4cc and from mov would have a mov-4cc I: make our own independant system which contains an id for every id in every other container (this could of course be done in 2 fields like format and implementation) IA: store our own id and a source format id if available AA: store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc... IAA:store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc and require a nut-id) AAA:store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc and require a AVI-4cc)
if we dont care about XXX->NUT->XXX a: adopt a single existing id system like the one from avi or mov b: like a but remap a few ids we dont like due to philosophical reasons i: design our own indepenant system for per format ids (no implemtation id)
A I IA AA IAA a-avi a-mov b i AAA supports old divx/xvid streams: X X X X X X X AVI->NUT->AVI wont change 4cc: X X X X X X X MOV->NUT->MOV wont change 4cc: X X X X X X X no table maintaince: X X X X x X decoder can use existing tables:X X X x X X X decoder needs single nut-table: X X X X X X X X encoder doesnt need to remap id:X X x
so, nothing is perfect, we cant have everything ...
here are a few personal comments AA vs. A both muxer and demuxer complexity are the same the only difference is that the muxer can store more ids if it knows them in AA, which might help the decoder if it doesnt know all id systems so IMHO we can drop A IA vs IAA if we already support multiple ids per file then allowing to store more then 2 doesnt seem like a big differnce and might be slightly better in some cases, so id say drop IA a-avi vs. a-mov there are more avi fourccs then mov fourccs so IMHO a-avi would be a better choice, theres also the old xvid/divx advantage, IIRC theres no distinction between the 2 in mov, so IMHO we can drop a-mov b vs. a-avi b is philsophical better at the cost of playability of a very small number of divx & xvid videos and it needs a little more maintainance so IMHO we can drop b in favor of a-avi i vs I if we are really building our own format id table then i guess a field more for the implemenattion wont hurt so IMHO drop i AA vs. AAA AA has a big problem, the nut file could use any id system, so this moves alot of complexity to the demuxer, so i belive its not controversical if i drop it in favor of some other system like AAA or another one which does the remaping at the muxer side
whats left: I AAA IAA a-avi supports old divx/xvid streams: X X X X AVI->NUT->AVI wont change 4cc: X X X X MOV->NUT->MOV wont change 4cc: X X X no table maintaince: X X decoder can use existing tables: X x X decoder only needs single table:X X X X encoder doesnt need to remap id:
alternative suggestions, and comments welcome, personally iam fine with all the options left (for I and IAA a volunteer would be needed to maintain a few tables)
Excellent analysis. I guess there is no need to say I am in favour of IAA system. We need compatibility (so 'I' is out) I demand creating our own system. The purpose - once the other formats are obsolete this system will be the only valid. (this eliminates i-avi and AAA). I had proposed 'I' type system in my "Fourcc vs format_id" mail. In short: "format_id" - string with the format specific stream. Must not overlap with any of the existing systems. No acronyms. "profile" - used capabilities of the profile. (hw players quick rejection, stream servers support). "encoder" string describing the encoder&version(used for bugs workaround and fame/blame of quality).
On Tue, Jun 27, 2006 at 10:48:20PM +0300, Ivan Kalvachev wrote:
alternative suggestions, and comments welcome, personally iam fine with all the options left (for I and IAA a volunteer would be needed to maintain a few tables)
Excellent analysis. I guess there is no need to say I am in favour of IAA system.
We need compatibility (so 'I' is out)
I demand creating our own system. The purpose - once the other formats are obsolete this system will be the only valid. (this eliminates i-avi and AAA).
I had proposed 'I' type system in my "Fourcc vs format_id" mail. In short: "format_id" - string with the format specific stream. Must not overlap with any of the existing systems. No acronyms. "profile" - used capabilities of the profile. (hw players quick rejection, stream servers support). "encoder" string describing the encoder&version(used for bugs workaround and fame/blame of quality).
And I strongly dislike this. Most of the information is not known by the program generating the file and should not need to be known. Different profiles can already have their own different format ids. Separating to multiple fields just creates complexity for complexity's sake which is bad. Rich
On Tue, Jun 27, 2006 at 06:34:05PM +0200, Michael Niedermayer wrote:
Hi
On Sat, Jun 24, 2006 at 01:27:24PM +0200, Michael Niedermayer wrote: [...]
in principle iam fine with any id system as long as its realistic (=people proposing complex stuff for nut must demonstrate the feasability of it first by implementing it) i also dont really care about being able to store broken mp4 in nut but i wont agree to a system being accepted based on a lie that it will work with every stream ...
so IMHO a id system must be able to achive the following, if it doesnt then IMHO its not worth considering 1. streamcopy (without decoder) every valid non broken stream from avi,mov,ogg to nut and produce a valid and playable file
of course the avi case needs pts=dts to be valid to begin with
Maybe so, but this is false for 99% of relevant avi files.
2. streamcopy every such file back to its source container and still have a valid and playable file
if we want XXX->NUT->XXX to work with preserving the id then we could either
A: allow any id to be used, so files converted from avi would contain a avi-4cc and from mov would have a mov-4cc
This is fine with me except for the twocc audio crap which is questionable...
I: make our own independant system which contains an id for every id in every other container (this could of course be done in 2 fields like format and implementation)
Ugly, redundant, bloated.
IA: store our own id and a source format id if available AA: store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc... IAA:store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc and require a nut-id) AAA:store as many ids as the muxer can map the input to (AVI-4cc and MOV-4cc and require a AVI-4cc)
if we dont care about XXX->NUT->XXX
I don't care about it. Do others?
a: adopt a single existing id system like the one from avi or mov b: like a but remap a few ids we dont like due to philosophical reasons i: design our own indepenant system for per format ids (no implemtation id)
A I IA AA IAA a-avi a-mov b i AAA supports old divx/xvid streams: X X X X X X X AVI->NUT->AVI wont change 4cc: X X X X X X X MOV->NUT->MOV wont change 4cc: X X X X X X X no table maintaince: X X X X x X decoder can use existing tables:X X X x X X X decoder needs single nut-table: X X X X X X X X encoder doesnt need to remap id:X X x
To me, the critical ones are: - no table maintaince - using existing tables or existing tables with a few minor additions IMO "encoder doesnt need to remap id" is odd, maybe this means "remuxer from other format doesn't need to remap id"?
so, nothing is perfect, we cant have everything ...
here are a few personal comments AA vs. A both muxer and demuxer complexity are the same the only difference is that the muxer can store more ids if it knows them in AA, which might help the decoder if it doesnt know all id systems so IMHO we can drop A IA vs IAA if we already support multiple ids per file then allowing to store more then 2 doesnt seem like a big differnce and might be slightly better in some cases, so id say drop IA
I agree with your reasoning here.
a-avi vs. a-mov there are more avi fourccs then mov fourccs so IMHO a-avi would be a better choice, theres also the old xvid/divx advantage, IIRC theres no distinction between the 2 in mov, so IMHO we can drop a-mov b vs. a-avi b is philsophical better at the cost of playability of a very small number of divx & xvid videos and it needs a little more maintainance so IMHO we can drop b in favor of a-avi i vs I if we are really building our own format id table then i guess a field more for the implemenattion wont hurt so IMHO drop i AA vs. AAA AA has a big problem, the nut file could use any id system, so this moves alot of complexity to the demuxer, so i belive its not controversical if i drop it in favor of some other system like AAA or another one which does the remaping at the muxer side
If the avi-style fourcc is required, it seems a bit odd to have other format ids too. Any demuxer implementation will have to be able to read the avi fourcc (in case it's the only one there), so what's the good of having more ids? The only way I find the AAA option interesting is if we require one of the ids to refer to a bitstream standard (instead of implementation) whenever the stream is standards-conformant. This would allow players that don't support proprietary codecs and don't want to deal with all the fourcc mess of those to play files without a table of all the implementation ids, and would allow players to play files encoded with new implementations (of mpeg4, etc.) without upgrading their tables. (SHOULD instead of MUST would also be acceptable here, with the implication that users may have to upgrade their players unnecessarily to play files ignoring the recommendation.)
whats left: I AAA IAA a-avi supports old divx/xvid streams: X X X X AVI->NUT->AVI wont change 4cc: X X X X MOV->NUT->MOV wont change 4cc: X X X no table maintaince: X X decoder can use existing tables: X x X decoder only needs single table:X X X X encoder doesnt need to remap id:
alternative suggestions, and comments welcome, personally iam fine with all the options left (for I and IAA a volunteer would be needed to maintain a few tables)
I generally dislike anything involving nut-id. It's just like matroska, useless bloat. Otherwise I'm mostly ok with AAA or a-avi. Perhaps with the above addition to AAA. Rich
Hi On Tue, Jun 27, 2006 at 04:00:26PM -0400, Rich Felker wrote: [...]
a: adopt a single existing id system like the one from avi or mov b: like a but remap a few ids we dont like due to philosophical reasons i: design our own indepenant system for per format ids (no implemtation id)
A I IA AA IAA a-avi a-mov b i AAA supports old divx/xvid streams: X X X X X X X AVI->NUT->AVI wont change 4cc: X X X X X X X MOV->NUT->MOV wont change 4cc: X X X X X X X no table maintaince: X X X X x X decoder can use existing tables:X X X x X X X decoder needs single nut-table: X X X X X X X X encoder doesnt need to remap id:X X x
To me, the critical ones are: - no table maintaince - using existing tables or existing tables with a few minor additions
IMO "encoder doesnt need to remap id" is odd, maybe this means "remuxer from other format doesn't need to remap id"?
yes [...]
a-avi vs. a-mov there are more avi fourccs then mov fourccs so IMHO a-avi would be a better choice, theres also the old xvid/divx advantage, IIRC theres no distinction between the 2 in mov, so IMHO we can drop a-mov b vs. a-avi b is philsophical better at the cost of playability of a very small number of divx & xvid videos and it needs a little more maintainance so IMHO we can drop b in favor of a-avi i vs I if we are really building our own format id table then i guess a field more for the implemenattion wont hurt so IMHO drop i AA vs. AAA AA has a big problem, the nut file could use any id system, so this moves alot of complexity to the demuxer, so i belive its not controversical if i drop it in favor of some other system like AAA or another one which does the remaping at the muxer side
If the avi-style fourcc is required, it seems a bit odd to have other format ids too. Any demuxer implementation will have to be able to read the avi fourcc (in case it's the only one there), so what's the good of having more ids?
The only way I find the AAA option interesting is if we require one of the ids to refer to a bitstream standard (instead of implementation) whenever the stream is standards-conformant. This would allow players that don't support proprietary codecs and don't want to deal with all the fourcc mess of those to play files without a table of all the implementation ids, and would allow players to play files encoded with new implementations (of mpeg4, etc.) without upgrading their tables.
(SHOULD instead of MUST would also be acceptable here, with the implication that users may have to upgrade their players unnecessarily to play files ignoring the recommendation.)
whats left: I AAA IAA a-avi supports old divx/xvid streams: X X X X AVI->NUT->AVI wont change 4cc: X X X X MOV->NUT->MOV wont change 4cc: X X X no table maintaince: X X decoder can use existing tables: X x X decoder only needs single table:X X X X encoder doesnt need to remap id:
alternative suggestions, and comments welcome, personally iam fine with all the options left (for I and IAA a volunteer would be needed to maintain a few tables)
I generally dislike anything involving nut-id. It's just like matroska, useless bloat.
well, as we still dont have volunteer for maintaining nut-id and no initial nut-id table either, I/IAA options are pretty dead anyway ivan do you volunteer to do the work? and can you make a table containing all 4cc of avi & mov with nice format & implementation names? if no then I/IAA style is dead we dont even need to disscuss their advantages its simply not possible like if you have no money you cant buy something / no volunteer -> no table -> no I/IAA
Otherwise I'm mostly ok with AAA or a-avi. Perhaps with the above addition to AAA.
ok, so after alot of flames we are back to the old system ... id is fourcc from AVI maybe allow additional ids (info packet or stream header?) maybe an additional standard format id for cases where fourcc has been abused to advertise the implementation name [...] -- 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
2006/6/27, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Tue, Jun 27, 2006 at 04:00:26PM -0400, Rich Felker wrote: [...]
a: adopt a single existing id system like the one from avi or mov b: like a but remap a few ids we dont like due to philosophical reasons i: design our own indepenant system for per format ids (no implemtation id)
A I IA AA IAA a-avi a-mov b i AAA supports old divx/xvid streams: X X X X X X X AVI->NUT->AVI wont change 4cc: X X X X X X X MOV->NUT->MOV wont change 4cc: X X X X X X X no table maintaince: X X X X x X decoder can use existing tables:X X X x X X X decoder needs single nut-table: X X X X X X X X encoder doesnt need to remap id:X X x
To me, the critical ones are: - no table maintaince - using existing tables or existing tables with a few minor additions
IMO "encoder doesnt need to remap id" is odd, maybe this means "remuxer from other format doesn't need to remap id"?
yes
[...]
a-avi vs. a-mov there are more avi fourccs then mov fourccs so IMHO a-avi would be a better choice, theres also the old xvid/divx advantage, IIRC theres no distinction between the 2 in mov, so IMHO we can drop a-mov b vs. a-avi b is philsophical better at the cost of playability of a very small number of divx & xvid videos and it needs a little more maintainance so IMHO we can drop b in favor of a-avi i vs I if we are really building our own format id table then i guess a field more for the implemenattion wont hurt so IMHO drop i AA vs. AAA AA has a big problem, the nut file could use any id system, so this moves alot of complexity to the demuxer, so i belive its not controversical if i drop it in favor of some other system like AAA or another one which does the remaping at the muxer side
If the avi-style fourcc is required, it seems a bit odd to have other format ids too. Any demuxer implementation will have to be able to read the avi fourcc (in case it's the only one there), so what's the good of having more ids?
The only way I find the AAA option interesting is if we require one of the ids to refer to a bitstream standard (instead of implementation) whenever the stream is standards-conformant. This would allow players that don't support proprietary codecs and don't want to deal with all the fourcc mess of those to play files without a table of all the implementation ids, and would allow players to play files encoded with new implementations (of mpeg4, etc.) without upgrading their tables.
(SHOULD instead of MUST would also be acceptable here, with the implication that users may have to upgrade their players unnecessarily to play files ignoring the recommendation.)
whats left: I AAA IAA a-avi supports old divx/xvid streams: X X X X AVI->NUT->AVI wont change 4cc: X X X X MOV->NUT->MOV wont change 4cc: X X X no table maintaince: X X decoder can use existing tables: X x X decoder only needs single table:X X X X encoder doesnt need to remap id:
alternative suggestions, and comments welcome, personally iam fine with all the options left (for I and IAA a volunteer would be needed to maintain a few tables)
I generally dislike anything involving nut-id. It's just like matroska, useless bloat.
well, as we still dont have volunteer for maintaining nut-id and no initial nut-id table either, I/IAA options are pretty dead anyway ivan do you volunteer to do the work? and can you make a table containing all 4cc of avi & mov with nice format & implementation names?
No problem. That's easy. I hope you don't want it with past date. It needs few hours work. Of course I'll do it only if the format_id is really going to be used. I'd like discusion to be based on arguments and reasoning, not what Dick likes and what not.
On Wed, Jun 28, 2006 at 12:54:16AM +0300, Ivan Kalvachev wrote:
I generally dislike anything involving nut-id. It's just like matroska, useless bloat.
well, as we still dont have volunteer for maintaining nut-id and no initial nut-id table either, I/IAA options are pretty dead anyway ivan do you volunteer to do the work? and can you make a table containing all 4cc of avi & mov with nice format & implementation names?
No problem. That's easy.
It is not easy and you'll have an even harder time getting anyone to adopt it.
I hope you don't want it with past date. It needs few hours work. Of course I'll do it only if the format_id is really going to be used.
Unlikely.
I'd like discusion to be based on arguments and reasoning, not what Dick likes and what not.
Apparently you missed the argument. To quote: "It's just like matroska, useless bloat" I didn't go into any more detail because I already explained what I mean by this many times. Bloat means cost (in size, performance, or complexity -- in this case mainly complexity) is disproportionately large compared to practical benefit (which is zero here, so the bloat ratio is infinite). Making up our own id system would be a classic case of NIH syndrome. Rich
2006/6/28, Rich Felker <dalias@aerifal.cx>:
On Wed, Jun 28, 2006 at 12:54:16AM +0300, Ivan Kalvachev wrote:
I generally dislike anything involving nut-id. It's just like matroska, useless bloat.
well, as we still dont have volunteer for maintaining nut-id and no initial nut-id table either, I/IAA options are pretty dead anyway ivan do you volunteer to do the work? and can you make a table containing all 4cc of avi & mov with nice format & implementation names?
No problem. That's easy.
It is not easy and you'll have an even harder time getting anyone to adopt it.
I hope you don't want it with past date. It needs few hours work. Of course I'll do it only if the format_id is really going to be used.
Unlikely.
I'd like discusion to be based on arguments and reasoning, not what Dick likes and what not.
Apparently you missed the argument. To quote:
"It's just like matroska, useless bloat"
I didn't go into any more detail because I already explained what I mean by this many times. Bloat means cost (in size, performance, or
Sorry my psychic powers are quite miserable lately and I cannot guess what do you mean. Obviously you should stop making claims and do more explanations.
complexity -- in this case mainly complexity) is disproportionately large compared to practical benefit (which is zero here, so the bloat ratio is infinite). Making up our own id system would be a classic case of NIH syndrome.
If there was 1 _single_ existing tag system that is fulfilling our requirements then there wouldn't be anything to argue about. So if there is no sane system we should at least _try_ to invent one. And I don't mean to take random bits from other tag system and stock them toggether, hoping they will stick.
Hi On Thu, Jun 29, 2006 at 09:47:05AM +0300, Ivan Kalvachev wrote: [...]
So if there is no sane system we should at least _try_ to invent one.
we? you want it, you would have to do all the work and maintain it until you find someone else to take over maintainership until now noone has done any work toward a new id system so for me the case is closed, the system will be avi-fourcc based, if you want something else you can still invent and propose another system noone will promisse that any of it will be used, decissions are made on technical terms, that was always the case when i, oded or rich suggested something and it turned out bad it was discarded too [...] -- 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
2006/6/29, Michael Niedermayer <michaelni@gmx.at>:
Hi
On Thu, Jun 29, 2006 at 09:47:05AM +0300, Ivan Kalvachev wrote: [...]
So if there is no sane system we should at least _try_ to invent one.
we? you want it, you would have to do all the work and maintain it until you find someone else to take over maintainership
until now noone has done any work toward a new id system so for me the case is closed, the system will be avi-fourcc based, if you want something
We can't use avi-fourcc. It doesn't have fourcc for audio. And the audio-tags are not even complete (remember adding support for custom audio-tags, coz some new formats don't have official one???).
Ivan Kalvachev wrote:
We can't use avi-fourcc.
Prepare the tables and patch libnut and mplayer. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
On Thu, Jun 29, 2006 at 11:14:23AM +0200, Michael Niedermayer wrote:
Hi
On Thu, Jun 29, 2006 at 09:47:05AM +0300, Ivan Kalvachev wrote: [...]
So if there is no sane system we should at least _try_ to invent one.
we? you want it, you would have to do all the work and maintain it until you find someone else to take over maintainership
until now noone has done any work toward a new id system so for me the case is closed, the system will be avi-fourcc based, if you want something else you can still invent and propose another system
before proposing another system please tell us what specific concrete problems will result from using avi-style fourcc.
noone will promisse that any of it will be used, decissions are made on technical terms, that was always the case
i'd still like to see any attempt at explaining how a new naming system can have a technical advantage.
when i, oded or rich suggested something and it turned out bad it was discarded too
not necessarily bad, sometimes just impractical/infeasible. rich
2006/6/30, Rich Felker <dalias@aerifal.cx>:
On Thu, Jun 29, 2006 at 11:14:23AM +0200, Michael Niedermayer wrote:
Hi
On Thu, Jun 29, 2006 at 09:47:05AM +0300, Ivan Kalvachev wrote: [...]
So if there is no sane system we should at least _try_ to invent one.
we? you want it, you would have to do all the work and maintain it until you find someone else to take over maintainership
until now noone has done any work toward a new id system so for me the case is closed, the system will be avi-fourcc based, if you want something else you can still invent and propose another system
before proposing another system please tell us what specific concrete problems will result from using avi-style fourcc.
noone will promisse that any of it will be used, decissions are made on technical terms, that was always the case
i'd still like to see any attempt at explaining how a new naming system can have a technical advantage.
when i, oded or rich suggested something and it turned out bad it was discarded too
not necessarily bad, sometimes just impractical/infeasible.
-- a-avi system. Use all avi tags 1:1. - avi audio doesn't have 4cc, but 2 byte codes (wav-2bc). Some formats doesn't even have them (that's why you can set them manually in ffmpeg/mplayer). - some formats have multiple fourcc. We need to either support them all (a-avi) or create&maintain our own list (i-avi). Both approach reqiure some kind of table and maintenance. - player not aware of avi-4cc would need avi table/support. -- Other a-* systems, more particularly a-mov have already been eliminated by Michael. Strangely matroska people seem to prefer it. -- b-A system. Addopt selected 4cc from many different systems. Mainly avi & mov. It was actually proposed to commit in nut. - players that don't support both avi or mov would need mapping table. - we have to maintain table. - there is no way to prevent other from turning it into "b" only system by using a-avi and a-mov fourcc. -- AA system. I split it on 2 other systems, -- random-AA Include multiple tags for one format, hoping the demuxer would recognize one of it. e.g. converting file and leaving its original tags (4cc,2bc,uuid,mkv-id,etc..) intact or including few other known aliases. - playable only from players that know these tags&aliases. (e.g. qt won't player avi-xvid). - no way to predict what tags the players will know. - many redundant tags. -- a-AA system Require all know tags to be included for every stream. - need to maintain table. - many more redundant tags for every stream. -- IAA system. Include our "I" tag and some of know AA tags. When transcoding - need to maintain table We don't have to include all know tags if player supports the "I" table. Player could omit the table and relay only on AA tags, this way reducing to original non-nut format behaviour (may or may not know the fourcc). Thoughts: My original proposition was about AA system. I think that it is mandatory whatever system we accept, it have to be kind of AA. It guarantees that converted files would still be playable on players that were able to play them before conversion. AA systems needs to be variable size. 2bc, 4cc, uuid, mkv - all have different sizes. We can start with AA system and later then make it IAA. Or have mandatory "I" system. p.s. I'm sure we could drive in curcles for very long time. We need some goals for the tag system.
On Thu, Jun 29, 2006 at 09:47:05AM +0300, Ivan Kalvachev wrote:
If there was 1 _single_ existing tag system that is fulfilling our requirements then there wouldn't be anything to argue about.
Yes.
So if there is no sane system we should at least _try_ to invent one.
NO! Inventing one just means that there are N+1 systems rather than N systems! It takes us farther from the goal, not closer! Moreover all of the existing systems meet our goals except for philosophical/aesthetic goals with no practical requirement. Rich
participants (6)
-
Ivan Kalvachev -
Luca Barbato -
Michael Niedermayer -
Måns Rullgård -
Oded Shimon -
Rich Felker