[FFmpeg-devel] XVMC Deathmatch

[Ivan Kalvachev]

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.

>> > 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.

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.
Despite the fact that it have known good sides.

In the case of my commits no breakage occurred.
In mpegvideo_xvmc.c the avcodec.h is included before xvmc(_pixfmt).h
So it would have had the correct defines.
MPlayer is another story, and I can point fingers left and right.
But nothing broke.

On the other side ABI breaking was especially forbidden.
It was broken with the promise that xvmc.h is not system installed,
however Diego himself made the xvmc.h header system installed (r17226).

So I'd call it even.

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 ;)

>> > 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.

> 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() ;)

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.
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) );

>> 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.