[FFmpeg-cvslog] random thoughts about SoC (was: Re: random thoughts about refactoring)

Mon Jan 11 20:32:21 CET 2010

On Mon, Jan 11, 2010 at 09:29:02AM +0100, Diego Biurrun wrote:
> On Mon, Jan 11, 2010 at 05:01:33AM +0100, Michael Niedermayer wrote:
> > On Mon, Jan 11, 2010 at 12:08:22AM +0100, Diego Biurrun wrote:
> > > On Sun, Jan 10, 2010 at 11:13:31PM +0100, Michael Niedermayer wrote:
> > > > On Sun, Jan 10, 2010 at 10:45:16PM +0100, Diego Biurrun wrote:
> > > > > On Sun, Jan 10, 2010 at 10:23:34PM +0100, Michael Niedermayer wrote:
> > > > > > On Sun, Jan 10, 2010 at 02:48:00PM -0500, compn wrote:
> > > > > > > 
> > > > > > > i'll paste some relevent irc chat:
> > > > > > 
> > > > > > thank you!
> > > > > > while not as usefull as i thought, it is usefull.
> > > > > > 
> > > > > > some comments below
> > > > > > 
> > > > > > > [17:49] <DonDiego> Dark_Shikari: we have no students who reach the patch review phase, so this is not a problem
> > > > > > 
> > > > > > ehm? there are plenty who did reach patch review, theres even a patch laying
> > > > > > around that i should review. You make it look quite a bit worse than it is
> > > > > 
> > > > > SoC is not going too well and what's worse, it's not improving year over
> > > > > year..
> > > > 
> > > > Thats not ffmpeg specific.
> > > 
> > > I was not talking about any other projects, I know no statistics for
> > > others.
> > 
> > Knowing about other projects in similar situations and how the try to
> > solve it and how and if that was successfull seems better to me than to
> > simply assume you are right and the soc mentors are all wrong
> 
> Yeah, just deny any problems, that will make them go away.  SoC is going
> perfect.  All the discussions I had with other project members (including
> mentors) are make-believe.  There is nothing to worry about, not now nor
> in the future.

Let me summarize it again
1. You claim that there is a problem
2. You claim that that your suggestion will solve it
3. You confirmed that you know of no single other project for which this
   solution worked.
4. You claim that there is a silent mysterious public that agrees with you,
   which is something you commonly use as an "argument"

1+2+3 is exactly what is used to pass some of the worst laws ever,
It goes like, theres a threat from terrorists, we must solve this, my solution
works even if it failed for others and iam not interested in bothering to
learn if the problem is solveable or if the sideeffects of a solution might
be worse.

That being mixed with trying to lay words in my mouth i did not say
soc is going perfect. Iam saying that your suggestion would make it worse

I also think that if you refuse to look at other projects that you are
not really qualified to suggest improvments. knowing the existing facts
is pretty much a prerequesite.
jason made suggestions like IRC and similar qual tasks these are based
on what actually works for x264 and iam in favor of them.

[...]

> 
> > > > also, ffmpeg is made of many parts, encoders, decoders, muxers, demuxers
> > > > and alot in between. If you split the students we have over these there arent
> > > > that many left in each category, now saying there are just 2 in one specific
> > > > category is a little weak.
> > > > 
> > > > just a quick grep for a random student name:
> > > > libavcodec/ac3dec.c: * Copyright (c) 2007-2008 Bartlomiej Wolowiec <bartek.wolowiec at gmail.com>
> > > > libavcodec/ac3dec_data.c: * Copyright (c) 2007 Bartlomiej Wolowiec <bartek.wolowiec at gmail.com>
> > > > libavcodec/eac3dec.c: * Copyright (c) 2007 Bartlomiej Wolowiec <bartek.wolowiec at gmail.com>
> > > > libavcodec/eac3dec_data.c: * Copyright (c) 2007 Bartlomiej Wolowiec <bartek.wolowiec at gmail.com>
> > > > libavcodec/lzwenc.c: * Copyright (c) 2007 Bartlomiej Wolowiec
> > > > libavcodec/lzwenc.c: * @author Bartlomiej Wolowiec
> > > > libavcodec/nellymoserenc.c: * Copyright (c) 2008 Bartlomiej Wolowiec
> > > > libavcodec/nellymoserenc.c: * by Bartlomiej Wolowiec
> > > > libavcodec/tiffenc.c: * Copyright (c) 2007 Bartlomiej Wolowiec
> > > > libavcodec/tiffenc.c: * @author Bartlomiej Wolowiec
> > > > libavformat/spdif.c: * Copyright (c) 2009 Bartlomiej Wolowiec
> > > > libavformat/spdif.c: * @author Bartlomiej Wolowiec
> > > 
> > > That's a straw man.  I mean what I say, not what you put into my mouth.
> > > 
> > > I never claimed we got nothing out of SoC nor am I unaware that demuxers
> > > are easier to write than decoders.  I was talking about decoders and my
> > > point still stands.
> > 
> > 10 matching in libavcodec 2 in libavformat, we dont have demuxers in
> > libavcodec
> > and thats just one student ...
> 
> Who did not finish his task, which is my whole point.
> 
> You keep attacking straw men.

not really no, i do not dispute that from the 6 or 7 arears of ffmpeg that
in the area you selected there are few soc projects that where successfull
from start to finish.

My counter arguments are that there are more areas you ignore and that there
was more done in these areas,aka you very obviously manipulate the statistic
in favor of your argument.

also our goal is not to maximise success but to maximize the amount of
useable code and to hopefully increase the ffmpeg team size

> 
> > > > > Our SoC tasks are too hard, it's a fact.
> > > > 
> > > > thats your oppinion and as you consider to apply for this years
> > > > soc ill surely not consider your oppinon as it could be heavily
> > > > biased due to personal interrest.
> > > 
> > > Everything is perfect.  You assess reality without flaw.  Nothing needs
> > > to be changed, ever.  FFmpeg must continue in all regards without
> > > adjusting course in the slightest.
> > 
> > we adjust course,
> 
> No, you don't. 

Sorry, a change of course that does not match what you would like to
see is still a change of course.

> When presented with criticism you keep attacking straw
> men and raising irrelevant points.

Your refusial to consider existing information is not irrelevant.
i will continue to suggest applications from students to be choosen
that i belive are likely successfull and usefull to us.
Not favor the simplest tasks to maximize a meaningless success statistic.

Any overestimaton of success we did has and is considered already.

[...]
> 
> It takes a thick skin and stubbornness to go up against you.  I have
> had my share, my tolerance of frustration is used up.  Good luck finding
> somebody else to tell you inconvenient truths.  I have little
> expectation, but I love nothing more than surprises in life,
> so my hope that somebody steps up to the task is sincere...

I love to hear peoples oppinion, and as you see i do consider them, like
what jason suggested about IRC and qual tasks. But not every suggestion
is good nor will i accept everything that is suggested. Most things raised
appear good to me and i will support them being made reality.
What you suggest is bad and iam against it. You refuse to accept this and
i tried to argue with you which possibly was a mistake but had i just told
you "no" you would have come up with some arguments behind my back of why
my lack of arguments makes my point wrong. Also no single other developer
supports your oppinion in public.

And again let me repeat we have always tried to select applications that we
belive will be successfull and we are hopefully getting better at estimating
that. Also i think the suggestions jason made could significatly improve
our success rate.
I dont think anything is gained from favoing applications that are much
simpler than what we belive the student is capable of.

> 
> > For example when kamil failed to write a j2k encoder and decoder
> > i insisted that we will not accept such combined tasks in the future
> 
> But then in 2009 look what do we have as project:
> 
>   Finish AMR-NB decoder *and* write an encoder
> 
> Not even the decoder got finished...
> 

so after falsely accusing me of attacking staw man you actually do
by first misquoting me and cutting half of what i said
I clearly said that decoder+encoder tasks if accpted would favor the decoder
and leave the encoder as an optional for later part that is not essential
for the projects success.

now lets please end this discussion
Ive listened to what you said and i disagree

> > > I'm sick and tired of these discussions.  First you complain loudly
> > > that you want to hear about all the problems that get talked about
> > > "behind your back", then you shoot at the messenger.
> > 
> > I do want to hear about the problems,
> 
> I can assure you that this has not improved anybody's motivation to
> report any in the future.

It sadens me that you cannot give up on your personal suggestion and
try to pull unrelated things in.
Thats even more so because if problems are hidden from me i cannot
consider them. Telling me about issues does not mean i will agree with
all, just that i will be aware of them and will try my best to improve
the situation.
also id like to mention it very clearly, compn posted the IRC log
he brought the issues forth, it was YOU who attacked compn for this and
then started this flame with me and now try to construct that flame into
something to support your initial point of preventing me from knowing
about all this in the first place.
Thats a very twisted thing

> 
> > That said, what simpler tasks would you have in mind that we should
> > suggest students to pick for their applications?
> 
> Finish previous SoC projects for example.

i never was against this, it seems you try to project some disagreements
you had with someone else onto me here.

>  Write a reasonably chosen
> part of a decoder/encoder, suitable for the next person to continue
> working on.

there are practical problems with this, like that the average student
will have difficulty continuing where the previous one stoped and that
such piecework is hard to test.
just look at how much difficulty jai had contiuing where kamil left off
which also shows that what you suggest here was done and failed.

>  Boost the performance of X, 

was suggested by us, no student accepted it

>demuxers, muxers (or a part
> of one),

was there, people did it and people succeeded some failed of course as well

> rtp network encapsulations, 

not sure what you mean here

> missing features of already
> existing formats,

was tried where such exists (PAFF IIRC) no student accepted it
and EAC3 which bartek did IIRC

> pick up a few things from the list of interesting
> patches, combine several simple tasks into a project, ...

iam not against it if the result is a 2month project
but you first must find a student willing to do this and iam not
so sure you would

[...]

> 
> > >   I'm not making the mistake again.  You know what happened to
> > > Cassandra when she stayed in Troy.  
> > 
> > actually no i dont, which of homers works do i have to read?
> 
> Wikipedia will provide sufficient information.

I prefer reading the primary literature or a translation where i dont know
the lanuage of it.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are 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/ffmpeg-cvslog/attachments/20100111/79af18c8/attachment.pgp>