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.