[FFmpeg-devel] XVMC Deathmatch

Sun Feb 22 00:32:30 CET 2009

On Sat, Feb 21, 2009 at 11:32:30PM +0200, Ivan Kalvachev wrote:
> On 2/18/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> > 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
> 
> I don't see answer of this question.
> 
> I'll say it this way. I signed for a match,
> not to fighting the World Coding War 1.
> 
> Anyway, It's been days since last commit by either of us around
> this code, so I guess it is already over.

yes, i confirm officially that the deathmatch is over.

> 
> >> > 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 can't refuse such kind offer.
> What you have to do it just give me tasks.

Well what kind of tasks would you like?
roundup is full of issues that need fixing both bugs and feature requests
if you cant decide i surely could try to find something of course ...

> 
> Despite some other people I don't demand the freedom
> to step on other people toes. ;)
> 
> >> > 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?
> 
> I've never liked the checkheaders madness to begin with.

neither did i :)

[...]
> It's like football game.
> It doesn't matter what really happened on the field,
> all that matters is what the referrer judged.
> (That's also why nobody likes them ;)

its seems iam reasonably lucky in that case that iam not yet sitting in a
pile of rotten tomatoes and eggs

> 
> >> > 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.
> 
> This is not assert limitation.
> 

> > We cant enable all asserts globally because some are in speed critical
> > code (kinda annoying for anything but debuging)
> 
> Asserts are only useful for debugging. This is what they are created for.

yes but if enabling all asserts makes ffmpeg run at 1/4 of the speed noone
will enable all, the 2 alternatives left are disabling all (again no info)
or having some kind of per file or per assert hint. we have per file
#undef NDEBUG hacks currently, this isnt clean and is in the way if
someone wants to enable/disable all. Also its unflexible as the
granularity is per file instead of per assert()

> 
> > 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
> 
> See, if you never want them disabled, then they should be using just if() ;)

this isnt a bad argument but it applies just to 1 of the 3 cases.

> 
> Also most likely the security relevant ones would be in the lowest level
> of pixel drawing code that also happens to be most speed critical.
> 
> > the stuff in the middle one might want disabled if one wants a binary as
> > small as possible.
> 
> Once again, if you want small binary it is good idea to disable all asserts.
> It is as simple as that: configure --enable-debug also enables all asserts.
> without it all are disabled.

as said above, if we did this --enable-debug would be too slow at runtime
-> noone would be using it -> the info would be missing from bugreports

what i want is to be able to
*disable all
*enable all
*enable all that dont matter speedwise (some kind of middle way that results
in a fully useable ffmpeg but still has most of the debug checks)

> If you rely on asserts to catch bugs in final program,
> check for security exploits, the
> you are probably doomed.
> 
> This notion is also why I've put assert() followed by return -1;
> Not to debug lavc but to catch bugs in the program calling lavc.
> 
> 
> If you still insist on asserts then I'd recommend doing something like
> mp_msg(type,level,...). Where you have "type" of the system indicating what
> system we want debugged and  "level" that indicates how speed critical
> the code is (aka disable the check if you want quick realtime trace,
> not excruciating pixel by pixel checks)
> 
> Aka: av_assert(DSP_SSE, 2 , !(ptr&15) );

iam not against this but it seems overkill

> 
> >> 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)
> > :)
> 
> I have only user account there.

no, you have a developer account on roundup since 2008-08-26 18:30:02
i upgrade all users to developers that i spot, but i surely miss many
and ive not gone over the list since some time

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

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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/20090222/9c2f8384/attachment.pgp>