Hi
On Thu, May 31, 2007 at 09:09:07PM +0200, Michael
Niedermayer wrote:
> 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 ...
additionally if we do end up agreeing with such a list then
ill be one of
the people maintaining it (and i know already that in that
case i would be
the only one really doing the work which is why iam not
happy about the
whole idea, but at least that will prevent the mess we ended
up with
root mphq ...)
mans hates avi thats why he volunteers but after nut does no
longer use
avi fourcc, i very much doubt he will be maintaining the
list
how would that codec tag - codec registration work?
do we choose the tag, does the person who contacted us
choose the tag?
what about common words, will we give them away to random
people?
what about random (windows) people who are unrelated to the
codec
authors, can they register tags?
and what about codecs which cant just be stored as is but
which need
some clarifications like the xiph codecs and their 3 global
packets
do we insist on a clear spec for each codec for which we
assign a
tag?
do we just say ok if someone want to register tag foo for
the foobar codec
or do we go and read the foobar spec and check if there
might be any
unclear parts which might lead to ambiguities when storing
it in nut
[...]
--
Michael GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself
and study your
own failings. Then you will forget your anger. -- Epictetus
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/nut-devel
|
