[nut]: r615 - docs/nut4cc.txt
Author: cladisch Date: Tue Feb 12 16:46:50 2008 New Revision: 615 Log: clarify which of the MPEG-4 video codecs is meant Modified: docs/nut4cc.txt Modified: docs/nut4cc.txt ============================================================================== --- docs/nut4cc.txt (original) +++ docs/nut4cc.txt Tue Feb 12 16:46:50 2008 @@ -32,7 +32,7 @@ MJPG ITU JPEG MPG4 MS MPEG4v1 (!NOT ISO MPEG4!) MP42 MS MPEG4v2 MP43 MS MPEG4v3 -MP4V ISO MPEG4 Video +MP4V ISO MPEG4 Part 2 Video mpg1 ISO MPEG1 Video mpg2 ISO MPEG2 Video MRLE MS RLE
On Tue, 12 Feb 2008, cladisch wrote:
Log: clarify which of the MPEG-4 video codecs is meant
-MP4V ISO MPEG4 Video +MP4V ISO MPEG4 Part 2 Video
Does this mean ISO MPEG4 Part 2 Advanced Simple Profile? Or are all profiles allowed and the rest just probably not supported by any given implementation? --Loren Merritt
On Mon, Feb 18, 2008 at 09:39:39AM -0700, Loren Merritt wrote:
On Tue, 12 Feb 2008, cladisch wrote:
Log: clarify which of the MPEG-4 video codecs is meant
-MP4V ISO MPEG4 Video +MP4V ISO MPEG4 Part 2 Video
Does this mean ISO MPEG4 Part 2 Advanced Simple Profile? Or are all profiles allowed and the rest just probably not supported by any given implementation?
I would say all are allowed, simply because the alternative is more work than any volunteer here is likely going to do. We already lacked one just writing this list ... Also this problem would apply to mpeg1/2 h264, h263, ... as well. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
On Mon, Feb 18, 2008 at 08:02:00PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 09:39:39AM -0700, Loren Merritt wrote:
On Tue, 12 Feb 2008, cladisch wrote:
Log: clarify which of the MPEG-4 video codecs is meant
-MP4V ISO MPEG4 Video +MP4V ISO MPEG4 Part 2 Video
Does this mean ISO MPEG4 Part 2 Advanced Simple Profile? Or are all profiles allowed and the rest just probably not supported by any given implementation?
I would say all are allowed, simply because the alternative is more work than any volunteer here is likely going to do. We already lacked one just writing this list ... Also this problem would apply to mpeg1/2 h264, h263, ... as well.
Does part 2 include all the ridiculous stuff like sprites? Rich
On Mon, Feb 18, 2008 at 02:12:57PM -0500, Rich Felker wrote:
On Mon, Feb 18, 2008 at 08:02:00PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 09:39:39AM -0700, Loren Merritt wrote:
On Tue, 12 Feb 2008, cladisch wrote:
Log: clarify which of the MPEG-4 video codecs is meant
-MP4V ISO MPEG4 Video +MP4V ISO MPEG4 Part 2 Video
Does this mean ISO MPEG4 Part 2 Advanced Simple Profile? Or are all profiles allowed and the rest just probably not supported by any given implementation?
I would say all are allowed, simply because the alternative is more work than any volunteer here is likely going to do. We already lacked one just writing this list ... Also this problem would apply to mpeg1/2 h264, h263, ... as well.
Does part 2 include all the ridiculous stuff like sprites?
---- Information technology Coding of audio-visual objects Part 2: Visual ... 7.9 Generalized scalable decoding 241 7.9.1 Temporal scalability ..241 7.9.2 Spatial scalability...246 7.10 Still texture object decoding.251 7.10.1 Decoding of the DC subband ...251 7.10.2 ZeroTree Decoding of the Higher Bands.252 7.10.3 Inverse Quantisation .257 7.10.4 Still Texture Error Resilience265 7.10.5 Wavelet Tiling.268 7.10.6 Scalable binary shape object decoding ..270 7.11 Mesh object decoding ... 276 7.11.1 Mesh geometry decoding . 276 7.11.2 Decoding of mesh motion vectors... 279 7.12 FBA object decoding. 281 7.12.1 Frame based face object decoding.. 281 7.12.2 DCT based face object decoding . 282 7.12.3 Decoding of the viseme parameter fap 1 284 7.12.4 Decoding of the viseme parameter fap 2 284 7.12.5 Fap masking ... 285 7.12.6 Frame Based Body Decoding... 285 7.12.7 DCT based body object decoding 286 7.13 3D Mesh Object Decoding 287 7.13.1 Start codes and bit stuffing .. 288 7.13.2 The Topological Surgery decoding process... 288 7.13.3 The Forest Split decoding process.. 291 7.13.4 Header decoder.. 292 7.13.5 partition type .. 293 7.13.6 Vertex Graph Decoder... 294 7.13.7 Triangle Tree Decoder... 298 7.13.8 Triangle Data Decoder... 299 7.13.9 Forest Split decoder .. 303 7.13.10 Arithmetic decoder 309 7.14 NEWPRED mode decoding... 314 7.14.1 Decoder Definition. 314 7.14.2 Upstream message 314 7.15 Output of the decoding process .. 314 7.15.1 Video data... 315 7.15.2 2D Mesh data.. 315 7.15.3 Face animation parameter data 315 8 Visual-Systems Composition Issues... 315 8.1 Temporal Scalability Composition... 315 8.2 Sprite Composition 316 8.3 Mesh Object Composition 317 8.4 Spatial Scalability composition 318 ----- [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
On Mon, Feb 18, 2008 at 09:25:47PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 02:12:57PM -0500, Rich Felker wrote:
On Mon, Feb 18, 2008 at 08:02:00PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 09:39:39AM -0700, Loren Merritt wrote:
On Tue, 12 Feb 2008, cladisch wrote:
Log: clarify which of the MPEG-4 video codecs is meant
-MP4V ISO MPEG4 Video +MP4V ISO MPEG4 Part 2 Video
Does this mean ISO MPEG4 Part 2 Advanced Simple Profile? Or are all profiles allowed and the rest just probably not supported by any given implementation?
I would say all are allowed, simply because the alternative is more work than any volunteer here is likely going to do. We already lacked one just writing this list ... Also this problem would apply to mpeg1/2 h264, h263, ... as well.
Does part 2 include all the ridiculous stuff like sprites?
---- Information technology Coding of audio-visual objects Part 2: Visual ... 7.9 Generalized scalable decoding 241 7.9.1 Temporal scalability ..241 7.9.2 Spatial scalability...246 7.10 Still texture object decoding.251 7.10.1 Decoding of the DC subband ...251 7.10.2 ZeroTree Decoding of the Higher Bands.252 7.10.3 Inverse Quantisation .257 7.10.4 Still Texture Error Resilience265 7.10.5 Wavelet Tiling.268 7.10.6 Scalable binary shape object decoding ..270 7.11 Mesh object decoding ... 276 7.11.1 Mesh geometry decoding . 276 7.11.2 Decoding of mesh motion vectors... 279 7.12 FBA object decoding. 281 7.12.1 Frame based face object decoding.. 281 7.12.2 DCT based face object decoding . 282 7.12.3 Decoding of the viseme parameter fap 1 284 7.12.4 Decoding of the viseme parameter fap 2 284 7.12.5 Fap masking ... 285 7.12.6 Frame Based Body Decoding... 285 7.12.7 DCT based body object decoding 286 7.13 3D Mesh Object Decoding 287 7.13.1 Start codes and bit stuffing .. 288 7.13.2 The Topological Surgery decoding process... 288 7.13.3 The Forest Split decoding process.. 291 7.13.4 Header decoder.. 292 7.13.5 partition type .. 293 7.13.6 Vertex Graph Decoder... 294 7.13.7 Triangle Tree Decoder... 298 7.13.8 Triangle Data Decoder... 299 7.13.9 Forest Split decoder .. 303 7.13.10 Arithmetic decoder 309 7.14 NEWPRED mode decoding... 314 7.14.1 Decoder Definition. 314 7.14.2 Upstream message 314 7.15 Output of the decoding process .. 314 7.15.1 Video data... 315 7.15.2 2D Mesh data.. 315 7.15.3 Face animation parameter data 315 8 Visual-Systems Composition Issues... 315 8.1 Temporal Scalability Composition... 315 8.2 Sprite Composition 316 8.3 Mesh Object Composition 317 8.4 Spatial Scalability composition 318 -----
Am I the only one who thinks this face animation, mesh, sprite, etc. crap that's never been implemented and probably never will be implemented in the real world belongs tucked away in its own obscure fourcc? Rich
On Mon, Feb 18, 2008 at 03:43:17PM -0500, Rich Felker wrote:
On Mon, Feb 18, 2008 at 09:25:47PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 02:12:57PM -0500, Rich Felker wrote:
On Mon, Feb 18, 2008 at 08:02:00PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 09:39:39AM -0700, Loren Merritt wrote:
On Tue, 12 Feb 2008, cladisch wrote:
Log: clarify which of the MPEG-4 video codecs is meant
-MP4V ISO MPEG4 Video +MP4V ISO MPEG4 Part 2 Video
Does this mean ISO MPEG4 Part 2 Advanced Simple Profile? Or are all profiles allowed and the rest just probably not supported by any given implementation?
I would say all are allowed, simply because the alternative is more work than any volunteer here is likely going to do. We already lacked one just writing this list ... Also this problem would apply to mpeg1/2 h264, h263, ... as well.
Does part 2 include all the ridiculous stuff like sprites?
---- Information technology Coding of audio-visual objects Part 2: Visual ... 7.9 Generalized scalable decoding 241 7.9.1 Temporal scalability ..241 7.9.2 Spatial scalability...246 7.10 Still texture object decoding.251 7.10.1 Decoding of the DC subband ...251 7.10.2 ZeroTree Decoding of the Higher Bands.252 7.10.3 Inverse Quantisation .257 7.10.4 Still Texture Error Resilience265 7.10.5 Wavelet Tiling.268 7.10.6 Scalable binary shape object decoding ..270 7.11 Mesh object decoding ... 276 7.11.1 Mesh geometry decoding . 276 7.11.2 Decoding of mesh motion vectors... 279 7.12 FBA object decoding. 281 7.12.1 Frame based face object decoding.. 281 7.12.2 DCT based face object decoding . 282 7.12.3 Decoding of the viseme parameter fap 1 284 7.12.4 Decoding of the viseme parameter fap 2 284 7.12.5 Fap masking ... 285 7.12.6 Frame Based Body Decoding... 285 7.12.7 DCT based body object decoding 286 7.13 3D Mesh Object Decoding 287 7.13.1 Start codes and bit stuffing .. 288 7.13.2 The Topological Surgery decoding process... 288 7.13.3 The Forest Split decoding process.. 291 7.13.4 Header decoder.. 292 7.13.5 partition type .. 293 7.13.6 Vertex Graph Decoder... 294 7.13.7 Triangle Tree Decoder... 298 7.13.8 Triangle Data Decoder... 299 7.13.9 Forest Split decoder .. 303 7.13.10 Arithmetic decoder 309 7.14 NEWPRED mode decoding... 314 7.14.1 Decoder Definition. 314 7.14.2 Upstream message 314 7.15 Output of the decoding process .. 314 7.15.1 Video data... 315 7.15.2 2D Mesh data.. 315 7.15.3 Face animation parameter data 315 8 Visual-Systems Composition Issues... 315 8.1 Temporal Scalability Composition... 315 8.2 Sprite Composition 316 8.3 Mesh Object Composition 317 8.4 Spatial Scalability composition 318 -----
Am I the only one who thinks this face animation, mesh, sprite, etc. crap that's never been implemented and probably never will be implemented in the real world belongs tucked away in its own obscure fourcc?
Well we would need a proper definition of what belongs in mp4v and what belongs in the other one. Also i fear if we want to do this half professional, we would have to provide sound arguments and tests why these things are useless and should be seperated. The general feeling that they are, which i think we all share is a little weak ... We also could sidestep above and just give each profile its own fourcc but that is going to be alot of work, and higher complexity on the muxer side, which has to figure out which profile a input mpeg4 is then ... Besides that i vote for the new fourcc to be "SHIT" if we end up doing a 4cc split :) Anyway, iam slightly leaning toward just leaving all in one 4cc. Because i just dont see any practical gain from the split, its just work, and work for which i dont vounteer ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct awnser.
On Tue, Feb 19, 2008 at 03:26:02AM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 03:43:17PM -0500, Rich Felker wrote:
On Mon, Feb 18, 2008 at 09:25:47PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 02:12:57PM -0500, Rich Felker wrote:
On Mon, Feb 18, 2008 at 08:02:00PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 09:39:39AM -0700, Loren Merritt wrote:
On Tue, 12 Feb 2008, cladisch wrote:
> Log: > clarify which of the MPEG-4 video codecs is meant > > -MP4V ISO MPEG4 Video > +MP4V ISO MPEG4 Part 2 Video
Does this mean ISO MPEG4 Part 2 Advanced Simple Profile? Or are all profiles allowed and the rest just probably not supported by any given implementation?
I would say all are allowed, simply because the alternative is more work than any volunteer here is likely going to do. We already lacked one just writing this list ... Also this problem would apply to mpeg1/2 h264, h263, ... as well.
Does part 2 include all the ridiculous stuff like sprites?
---- Information technology Coding of audio-visual objects Part 2: Visual ... 7.9 Generalized scalable decoding 241 7.9.1 Temporal scalability ..241 7.9.2 Spatial scalability...246 7.10 Still texture object decoding.251 7.10.1 Decoding of the DC subband ...251 7.10.2 ZeroTree Decoding of the Higher Bands.252 7.10.3 Inverse Quantisation .257 7.10.4 Still Texture Error Resilience265 7.10.5 Wavelet Tiling.268 7.10.6 Scalable binary shape object decoding ..270 7.11 Mesh object decoding ... 276 7.11.1 Mesh geometry decoding . 276 7.11.2 Decoding of mesh motion vectors... 279 7.12 FBA object decoding. 281 7.12.1 Frame based face object decoding.. 281 7.12.2 DCT based face object decoding . 282 7.12.3 Decoding of the viseme parameter fap 1 284 7.12.4 Decoding of the viseme parameter fap 2 284 7.12.5 Fap masking ... 285 7.12.6 Frame Based Body Decoding... 285 7.12.7 DCT based body object decoding 286 7.13 3D Mesh Object Decoding 287 7.13.1 Start codes and bit stuffing .. 288 7.13.2 The Topological Surgery decoding process... 288 7.13.3 The Forest Split decoding process.. 291 7.13.4 Header decoder.. 292 7.13.5 partition type .. 293 7.13.6 Vertex Graph Decoder... 294 7.13.7 Triangle Tree Decoder... 298 7.13.8 Triangle Data Decoder... 299 7.13.9 Forest Split decoder .. 303 7.13.10 Arithmetic decoder 309 7.14 NEWPRED mode decoding... 314 7.14.1 Decoder Definition. 314 7.14.2 Upstream message 314 7.15 Output of the decoding process .. 314 7.15.1 Video data... 315 7.15.2 2D Mesh data.. 315 7.15.3 Face animation parameter data 315 8 Visual-Systems Composition Issues... 315 8.1 Temporal Scalability Composition... 315 8.2 Sprite Composition 316 8.3 Mesh Object Composition 317 8.4 Spatial Scalability composition 318 -----
Am I the only one who thinks this face animation, mesh, sprite, etc. crap that's never been implemented and probably never will be implemented in the real world belongs tucked away in its own obscure fourcc?
Well we would need a proper definition of what belongs in mp4v and what belongs in the other one. Also i fear if we want to do this half professional, we would have to provide sound arguments and tests why these things are useless and should be seperated. The general feeling that they are, which i think we all share is a little weak ...
We also could sidestep above and just give each profile its own fourcc but that is going to be alot of work, and higher complexity on the muxer side, which has to figure out which profile a input mpeg4 is then ...
Besides that i vote for the new fourcc to be "SHIT" if we end up doing a 4cc split :)
Anyway, iam slightly leaning toward just leaving all in one 4cc. Because i just dont see any practical gain from the split, its just work, and work for which i dont vounteer ...
Can't we just say MP4V means MPEG-4 ASP? Or are there real features in use that are outside the domain of ASP? Rich
On Mon, Feb 18, 2008 at 10:36:08PM -0500, Rich Felker wrote:
On Tue, Feb 19, 2008 at 03:26:02AM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 03:43:17PM -0500, Rich Felker wrote:
On Mon, Feb 18, 2008 at 09:25:47PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 02:12:57PM -0500, Rich Felker wrote:
On Mon, Feb 18, 2008 at 08:02:00PM +0100, Michael Niedermayer wrote:
On Mon, Feb 18, 2008 at 09:39:39AM -0700, Loren Merritt wrote: > On Tue, 12 Feb 2008, cladisch wrote: > > > Log: > > clarify which of the MPEG-4 video codecs is meant > > > > -MP4V ISO MPEG4 Video > > +MP4V ISO MPEG4 Part 2 Video > > Does this mean ISO MPEG4 Part 2 Advanced Simple Profile? Or are all > profiles allowed and the rest just probably not supported by any given > implementation?
I would say all are allowed, simply because the alternative is more work than any volunteer here is likely going to do. We already lacked one just writing this list ... Also this problem would apply to mpeg1/2 h264, h263, ... as well.
Does part 2 include all the ridiculous stuff like sprites?
---- Information technology Coding of audio-visual objects Part 2: Visual ... 7.9 Generalized scalable decoding 241 7.9.1 Temporal scalability ..241 7.9.2 Spatial scalability...246 7.10 Still texture object decoding.251 7.10.1 Decoding of the DC subband ...251 7.10.2 ZeroTree Decoding of the Higher Bands.252 7.10.3 Inverse Quantisation .257 7.10.4 Still Texture Error Resilience265 7.10.5 Wavelet Tiling.268 7.10.6 Scalable binary shape object decoding ..270 7.11 Mesh object decoding ... 276 7.11.1 Mesh geometry decoding . 276 7.11.2 Decoding of mesh motion vectors... 279 7.12 FBA object decoding. 281 7.12.1 Frame based face object decoding.. 281 7.12.2 DCT based face object decoding . 282 7.12.3 Decoding of the viseme parameter fap 1 284 7.12.4 Decoding of the viseme parameter fap 2 284 7.12.5 Fap masking ... 285 7.12.6 Frame Based Body Decoding... 285 7.12.7 DCT based body object decoding 286 7.13 3D Mesh Object Decoding 287 7.13.1 Start codes and bit stuffing .. 288 7.13.2 The Topological Surgery decoding process... 288 7.13.3 The Forest Split decoding process.. 291 7.13.4 Header decoder.. 292 7.13.5 partition type .. 293 7.13.6 Vertex Graph Decoder... 294 7.13.7 Triangle Tree Decoder... 298 7.13.8 Triangle Data Decoder... 299 7.13.9 Forest Split decoder .. 303 7.13.10 Arithmetic decoder 309 7.14 NEWPRED mode decoding... 314 7.14.1 Decoder Definition. 314 7.14.2 Upstream message 314 7.15 Output of the decoding process .. 314 7.15.1 Video data... 315 7.15.2 2D Mesh data.. 315 7.15.3 Face animation parameter data 315 8 Visual-Systems Composition Issues... 315 8.1 Temporal Scalability Composition... 315 8.2 Sprite Composition 316 8.3 Mesh Object Composition 317 8.4 Spatial Scalability composition 318 -----
Am I the only one who thinks this face animation, mesh, sprite, etc. crap that's never been implemented and probably never will be implemented in the real world belongs tucked away in its own obscure fourcc?
Well we would need a proper definition of what belongs in mp4v and what belongs in the other one. Also i fear if we want to do this half professional, we would have to provide sound arguments and tests why these things are useless and should be seperated. The general feeling that they are, which i think we all share is a little weak ...
We also could sidestep above and just give each profile its own fourcc but that is going to be alot of work, and higher complexity on the muxer side, which has to figure out which profile a input mpeg4 is then ...
Besides that i vote for the new fourcc to be "SHIT" if we end up doing a 4cc split :)
Anyway, iam slightly leaning toward just leaving all in one 4cc. Because i just dont see any practical gain from the split, its just work, and work for which i dont vounteer ...
Can't we just say MP4V means MPEG-4 ASP? Or are there real features in use that are outside the domain of ASP?
64k will always be enough for everyone [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato
On Tue, Feb 19, 2008 at 06:54:06PM +0100, Michael Niedermayer wrote:
Besides that i vote for the new fourcc to be "SHIT" if we end up doing a 4cc split :)
Anyway, iam slightly leaning toward just leaving all in one 4cc. Because i just dont see any practical gain from the split, its just work, and work for which i dont vounteer ...
Can't we just say MP4V means MPEG-4 ASP? Or are there real features in use that are outside the domain of ASP?
64k will always be enough for everyone
That doesn't answer the question. Does ASP correspond directly to the currently implemented/used stuff, or not? If it does, I think we should make MP4V==ASP And I really don't see people going back and implementing features of an old standard that were essentially deemed mistakes by the userbase. If people eventually decide to try face/mesh/etc. crap in video compression, they'll do it with a newer more efficient bitstream format, not piggybacking it onto mpeg-4 asp implementations. And if I'm wrong, the SHIT fourcc is still available it seems... :-) Rich
On Tue, Feb 19, 2008 at 01:50:13PM -0500, Rich Felker wrote:
On Tue, Feb 19, 2008 at 06:54:06PM +0100, Michael Niedermayer wrote:
Besides that i vote for the new fourcc to be "SHIT" if we end up doing a 4cc split :)
Anyway, iam slightly leaning toward just leaving all in one 4cc. Because i just dont see any practical gain from the split, its just work, and work for which i dont vounteer ...
Can't we just say MP4V means MPEG-4 ASP? Or are there real features in use that are outside the domain of ASP?
64k will always be enough for everyone
That doesn't answer the question. Does ASP correspond directly to the currently implemented/used stuff, or not? If it does, I think we should make MP4V==ASP
What should the other profiles use? If you cannot awnser this then the container is not a generic container.
And I really don't see people going back and implementing features of an old standard that were essentially deemed mistakes by the userbase.
That has no relevance to the codec id system IMO. Also even though it is not relevant, its very well possible that some CS students would be forced by some looser professor to implement these other parts of mpeg4 part 2. But again its irrelevant, if nut is a generic container there needs to be a predictable way to identify mpeg4 (not only ASP).
If people eventually decide to try face/mesh/etc. crap in video compression, they'll do it with a newer more efficient bitstream format, not piggybacking it onto mpeg-4 asp implementations. And if I'm wrong, the SHIT fourcc is still available it seems... :-)
I honestly give a shit about your predictions of what people will do ;) It may be that you are correct but if we keep building a design based on such predictions eventually one (or all) will turn out false. I strongly belive we should design a system with a minimum set of restrictions. That is never add a restriction unless there is a proofen need adding restrictions based on hatred (even if we unanimously hate it) of specific things does not belong in nut IMO. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
On Tue, Feb 19, 2008 at 10:37:18PM +0100, Michael Niedermayer wrote:
I strongly belive we should design a system with a minimum set of restrictions. That is never add a restriction unless there is a proofen need adding restrictions based on hatred (even if we unanimously hate it) of specific things does not belong in nut IMO.
I don't think it's based on hate but on the fact that there's little practical possibility of implementing all the random things in part 2, whereas there's a well-defined profile of what actually is in use, and it's beneficial to players to know whether the stream will be playable by real-world decoders. As a concrete example, suppose some player has both lavc and some academic-toy reference implementation covering all of part 2 available. It would be helpful to know that it can play ordinary asp streams with lavc (with full-framerate decoding) as opposed to using the 0.1 fps toy-decoder for the experimental academic streams made by whoever implemented all those features. If you're still strongly opposed to making MP4V==ASP, I'll drop it, but I think there are valid reasons to consider specifying a profile. I'd be happy to also specify an "everything goes" part-2 fourcc if you like and it doesn't have to be "SHIT". =) Rich
On Tue, Feb 19, 2008 at 07:07:06PM -0500, Rich Felker wrote:
On Tue, Feb 19, 2008 at 10:37:18PM +0100, Michael Niedermayer wrote:
I strongly belive we should design a system with a minimum set of restrictions. That is never add a restriction unless there is a proofen need adding restrictions based on hatred (even if we unanimously hate it) of specific things does not belong in nut IMO.
I don't think it's based on hate but on the fact that there's little practical possibility of implementing all the random things in part 2, whereas there's a well-defined profile of what actually is in use, and it's beneficial to players to know whether the stream will be playable by real-world decoders.
As a concrete example, suppose some player has both lavc and some academic-toy reference implementation covering all of part 2 available. It would be helpful to know that it can play ordinary asp streams with lavc (with full-framerate decoding) as opposed to using the 0.1 fps toy-decoder for the experimental academic streams made by whoever implemented all those features.
If you're still strongly opposed to making MP4V==ASP, I'll drop it,
What about mpeg2, mpeg1, h263, h262, h261, h264 ? They have obscure profiles as well, will you just ignore them as you dont know about them? Or are you going to read the specs now? If you want i have some drafts laying around :)
but I think there are valid reasons to consider specifying a profile.
Yes, but you dont have that with a mp4v vs shit, theres alot more to it, just consider GMC, how many hw decoders support it? interlacing? all the error resilience features like data partitioning, reversible vlcs, ... You draw a line today based on what ffmpeg supports, in 5 years that could be completely inappropriate. It just needs a single encoder to support one of the obscure features and gain 1% with it. Look a few years in the past, ASP did NOT exist it was later added to mpeg4. Back then you would have choosen another profile for the big split. MPEG just needs to add a X protocol which supports OBMC (which is specified in th standard but not in any profiles) OBMC should improve compression significantly with a well written encoder ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
participants (4)
-
cladisch -
Loren Merritt -
Michael Niedermayer -
Rich Felker