Re: : r615 - docs/nut4cc.txt

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
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

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.

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel