Hi
On Thu, May 31, 2007 at 04:15:32PM +0300, Oded Shimon
wrote:
> On Thu, May 31, 2007 at 03:20:38AM +0200, Michael
Niedermayer wrote:
> > On Wed, May 30, 2007 at 06:47:47PM +0300, Oded
Shimon wrote:
> > > On Wed, Dec 27, 2006 at 11:54:40PM -0500,
Rich Felker wrote:
> > > > On Sun, Dec 24, 2006 at 01:21:00PM
+0100, Michael Niedermayer wrote:
> > > > > > Having a list makes no sense
unless it's normative for both sides.
> > > > >
> > > > > agree though thats a statement and
not a argument
> > > > > the argument ("proof" by
contradction) is that if the muxer can choose any
> > > > > fourcc for standard mpeg4 (not
buggy near mpeg4 ...) then a demuxer cannot
> > > > > support mpeg4 in nut with 100%
certainity, theres the very small possibility
> > > > > that mpeg4 would be stored with
another new and unknown fourcc ...
> > >
> > > Does this mean that we want a spec after all
which is normative both for
> > > muxers and demuxers?
> > > This would mean, there would be a single
table in the nut muxer
> > > implementation, and if muxing a codec which
does not have an entry in the
> > > table is attempted, muxing would fail. - The
resolution would be to
> > > contact us and the codec would be officially
added to the list, and then
> > > it could be muxed, until then it would be
impossible.
> > >
> > > I am not against this, as - this is a
bikeshed issue... What are your
> > > opinions on this? Rich, Michael, please
reply...
>
> [..]
>
> > > If we do the above suggestion - spec is
normative for muxers, then the
> > > answer is fairly easy - use our own new
"clean" fourcc list. I would see
> > > no argument against this, as NUT would have
its own completely fixed and
> > > seperate table...
> >
> > do we have a list that contains everything from http://www.fourcc.org/ ?
> > do we have at least 2 volunteers who dont mind
maintaining that list
> > indefinitly ?
> >
> > if the awnser is no to either of them then we dont
need to disscuss the
> > possibility of a normative list which is centrally
controlled as we fail
> > on the basic requirements for it ...
>
> I am willing to make a list for all codecs currently in
avocdec.h - that
> is all that would be relavent for a muxer in ffmpeg
anyway. I also
> talked to Mans here at LT, we agree to maintain this
list, "into the
> forseeable future"...
iam against a list maintained by mans
the reason is that he tends to do the things he maintains
just halfway
(he surely does that half which he does do well but that
doesnt help us
here ...)
that is issues related to the mpeg (de)muxers in ffmpeg
often get ignored
for a long time
also what is with the svn->git switch of ffmpeg? when i
first said i wanted
to switch ffmpeg to git the mphq roots where all apparently
wanting ffmpeg
to use mphq instead of another server
and whats now, ... yes simple. "no comment" root
is silent, sure its not
mans alone and surely he is busy but i at least would
appreceate a short
note on ffmpeg-dev about the status of the move
its not as if adding accounts for the people would be harder
than adding
codec tags to a list ...
[...]
--
Michael GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest
or treaty, and
there is nothing more to fear from them, then he is always
stirring up
some war or other, in order that the people may require a
leader. -- Plato
_______________________________________________
NUT-devel mailing list
NUT-devel mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
