On Thu, May 31, 2007 at 03:20:38AM +0200, Michael Niedermayer wrote:
On Wed, May 30, 2007 at 06:47:47PM +0300, Oded Shimon wrote:
On Wed, Dec 27, 2006 at 11:54:40PM -0500, Rich Felker wrote:
On Sun, Dec 24, 2006 at 01:21:00PM +0100, Michael Niedermayer wrote:
Having a list makes no sense unless it's normative for both sides.
agree though thats a statement and not a argument the argument ("proof" by contradction) is that if the muxer can choose any fourcc for standard mpeg4 (not buggy near mpeg4 ...) then a demuxer cannot support mpeg4 in nut with 100% certainity, theres the very small possibility that mpeg4 would be stored with another new and unknown fourcc ...
Does this mean that we want a spec after all which is normative both for muxers and demuxers? This would mean, there would be a single table in the nut muxer implementation, and if muxing a codec which does not have an entry in the table is attempted, muxing would fail. - The resolution would be to contact us and the codec would be officially added to the list, and then it could be muxed, until then it would be impossible.
I am not against this, as - this is a bikeshed issue... What are your opinions on this? Rich, Michael, please reply...
[..]
If we do the above suggestion - spec is normative for muxers, then the answer is fairly easy - use our own new "clean" fourcc list. I would see no argument against this, as NUT would have its own completely fixed and seperate table...
do we have a list that contains everything from http://www.fourcc.org/ ? do we have at least 2 volunteers who dont mind maintaining that list indefinitly ?
if the awnser is no to either of them then we dont need to disscuss the possibility of a normative list which is centrally controlled as we fail on the basic requirements for it ...
I am willing to make a list for all codecs currently in avocdec.h - that is all that would be relavent for a muxer in ffmpeg anyway. I also talked to Mans here at LT, we agree to maintain this list, "into the forseeable future"... - ods15