[MPlayer-dev-eng] [PATCH] Unichrome XvMC VLD support

[Ivor Hewitt]

On Wednesday 22 Sep 2004 13:55, Ivan Kalvachev wrote:
>
> mplayer -vo xvmc -vc ffmpeg12xxmc ;)
>
doh I've done it again.

Yes:
mplayer -vo xvmc -vc ffmpeg12mc

sigh. 

> Here are comments about the patch,
> the drawbacks of unichrome XvMC are in different mail.
>
I didn't read that, I'll search the archive for it.

> Look for the right set of options to use when making patch,
> Patch seems to apply but it looks funny when I'm watching it.
>
Sorry, I was using kompare to visually check the diffs and it had some extra 
flags set.

> Don't remove xvmc from the _(no)vomodules. They are different interfaces
> anyway.
>
I don't follow. I just moved the (no)vomodules setup to after the two test 
clauses so that it got inserted whichever one was used.

> Always add new PIX_FMT_ at the end. The enum numbers are
> used by binary packages of libavcodec and inserting new format
> will break compability.
>
Ah right. Will do.

> you can use xvmc_acceleration with some bitmask or special value
> (so far are used 0,1,2 i think) to indicate the acceleration level.
> This will keep unchanged some of the old if's and won't affect performance.
>
Ah, ok. I left that alone because it seemed to just set it to 2 and nothing 
else so I wasn't sure what would be valid values. I'll bags 4 then. :-)

> Why are you forcing the LIBMPEG2MMX idct algo?
> I'm not sure but it used some strange permutation.
>
Hmm I'll check that.

> Why are you creating new XVMC_VLD_field funtions, I already have
> XVMC_field - it just makes the code bigger. Especially if xvmcvideo.c
> will never be compiled with VLD...
>
I was thinking perhaps someone would compile the code linked to both VLD and 
NVIDIA. Also I thought there was significant additional difference with 
having the qmatrix code in there that the size saving by merging the two 
wouldn't be huge. Besides as you say, if they only compiled one or the other 
in they the resulting binary will only have one or the other in, surely 
smaller?

> "#ifdebug" missing closing ] will be commited imidiatly
>
yeah that threw my code highlighting out.

> hadVLDAcceleration() is not used in the xvmc_check_surface_format.
> but it is used on all other places.(
>
yeah I was just mirroring the existing 'if's so that the flag differences 
could be seen.

> "RenderSirface" will be commited imediatly
>
> There are reserved fields in xvmc_render_state_t, use them and
> don't make the structure bigger
>
Ok. do you want me to add new fields before reserved1 and reduce it's size? or 
use reserved[x] and cast?

> Now about the whole VLD acceleration.
> I would be happy if I should not commit it.
> BTW it is good if you send the patch to FFmpeg-dev maillist
> so the project leader could say that he think about it. I guess
> he will be less happier than me:(
> But if he accept it I will commit the whole patch.
>
hmmm. that doesn't sound good.

> Will reply to the other thread, so we all could flame without trashing
> patch thread ;)
>
Hmmm, I'm not particularly interested in getting into a flame war about 
anything. I'm just trying to provide some support for this hardware in 
mplayer.
I consider the xvmc-vld method of supporting this via mpeg acceleration 1000% 
times preferable to the libddmpeg option.

> Wish You Best
>    Ivan Kalvachev
>   iive
>
Thanks for you comments.


-- 
Ivor Hewitt.
http://www.ivor.it - tech | http://www.ivor.org - hedge