[NUT-devel] [nut]: r615 - docs/nut4cc.txt

[Michael Niedermayer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/nut-devel/attachments/20080220/66d7c165/attachment.pgp>