[FFmpeg-devel] XVMC Deathmatch

[Michael Niedermayer]

On Wed, Feb 18, 2009 at 11:00:57PM +0200, Ivan Kalvachev wrote:
> On 2/18/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Feb 18, 2009 at 10:33:21AM +0200, Ivan Kalvachev wrote:
> >> On 2/14/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> > On Sat, Feb 14, 2009 at 08:30:37PM +0000, Robert Swain wrote:
> >> >> 2009/2/14 Michael Niedermayer <michaelni at gmx.at>:
> >> >> > The review is below
> >> >>
> >> >> When is the competition set to end? Not that I want it to until
> >> >> there's nothing left to do on the file, but I think it's a question
> >> >> that needs to be asked.
> >> >
> >> > IIRC i originally said a period of 24h of no commits related to it
> >> > or so ...
> >>
> >> Would you define "related"
> >> e.g. Are grammar fixes such commits.
> >> imho one can improve wording indefinitely.
> >
> > are we in any hurry to end the deathmatch?
> 
> This is not what I've asked :E
> 
> > it would be better for the code if it would be running longer and
> > insensitive clod awnser ...
> 
> You know, you can just ask me nicely.

ivan, can you please do more coding work.
what you did in the last few days in xvmc was great, please continue,
and that doesnt have to be xvmc, we are for example shortly before a
release and there are many bugreports on roundup that should be fixed ...


> 
> 
> > i dont need you doing any other work at the moment so it would be silly
> > of me if i did something that stoped you working on xvmc.
> 
> Right now I've stopped completely working on it,

you are too predictable


> in fear that another forgotten space could bring some severe penalty.
> ( I know what thought just crossed your mind, forget it;)

what would you do with that past checkheaders breakage if you where in my
position?


> 
> > but if you want it to end sooner, just implement all that is left in my
> > list :)
> 
> I've long lost the track of what is done and what remains.
> 
> And there is some stuff from the category "I have no idea what he
> wants with that because the idea sounds really stupid, and he is not
> stupid."
> (e.g. the av_assert_security() stuff).

the av_assert* stuff basically is a soltution to the problem of having
asserts forced to on or off per file.
We cant enable all asserts globally because some are in speed critical
code (kinda annoying for anything but debuging)
thus spliting assert() in the 3 cases of speedcritical, normal and security
relevant

the speedcritical ones, one only wants activated for serious debuging
the security relevant ones, one never wants disabled

the stuff in the middle one might want disabled if one wants a binary as
small as possible.


> 
> As for designing and implementing the common hwaccel interface,
> I don't think it is suited task for lone fighting gladiator.
> It's better when these things are discussed and done together.

i suspect we soon will have the common hwaccel interface as patches
have alraedy been posted and probably will sooner or later pass review

besides, as a special offer to you, you get 1 point per fixed issue from
roundup (dont forget mentioning the issue number in the commit message) 
:)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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-devel/attachments/20090218/47370a08/attachment.pgp>