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

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

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

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

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

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.

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

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.

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

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

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

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

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

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