[MPlayer-dev-eng] [PATCH] YUV support for vo_quartz, at last

[Romain Dolbeau]

Camillo Lugaresi wrote:

> - Make sure all APIs are being called properly. I see NULL is being 
> passed as the destination port to DecompressSequenceBeginS; the 
> documentation does not say that passing NULL is supported, so it's 
> better to use GetWindowPort (I see this is in the code, but commented... 
> why?). Or point me at the docs that say you can pass NULL, I'd be glad 
> to learn something new. :)

IWFM (It Works For Me :-) That's mostly trial-and-error code.
Sometimes things work when they shouldn't, and you don't
change them for fear of breaking something...

> - Ensure you're letting QuickTime do its job in the fastest possible 
> way. I see codecFlagUseImageBuffer is being used, why is that? If there 
> are reasons to use it (even though it can slow things down), they should 
> be stated as comments in the source, so readers aren't left wondering.

The reason is, I never touched QuickTime coding before
vo_quartz, so I put the same flags as I've seen elsewhere.
Incidentally, w/o it, you're right, it seems faster for
packed YUV (doesn't seem any conversion occurs anymore).

 From planar YUV, yuv2packedXinC and hScale_altivec_real
still eats up CPU like mad. Letting QuickTime handle
the planar YUV by itself is *much* faster than forcing
the conversion in mplayer.

> I'd place it before vo_null, but after vo_sdl. SDL has been working well 
> enough; I wouldn't replace it as the default driver unless (until?) 
> vo_quartz proves to have better performance (measurements are needed).

For YV12, it's the same codepath, and about the same speed
(says gprof). For others, i don't know, because I don't know
what kinds of files prefer packed YUV as output. Any suggestion ?

-- 
Romain Dolbeau