[MPlayer-dev-eng] [PATCH] Replaced deprecated QuickDraw calls in vo_quartz

[Gregor Riepl]

>> this doesn't mean it's a good idea to get rid of deprecated calls,
>
> Well, besides QuitApplicationEventLoop, deprecated calls have been
> dealt with already, right?

woops, obvious typo. should read "this doesn't mean it's a NOT good  
idea to get rid of deprecated calls"
but yeah. i just meant it like this: in case anyone would have  
objected to the changes. :)

>> but it makes a 64bit os x port more questionable. to me at least.
>
> It's a good idea to work on this in advance, before many users ask for
> it. Also, this enables to use MEncoder in 64-bits mode, which is quite
> cool since most codecs are faster when compiled in 64-bits mode.

is that true? i didn't measure codec performance, only that of fspp.

>> Why is this necessary? Does OSX 64 bit not support relocations _at  
>> all_?
>
> Yes, it does, see this doc:
> http://developer.apple.com/DOCUMENTATION/DeveloperTools/Conceptual/MachOTopics/Articles/dynamic_code.html#/ 
> /apple_ref/doc/uid/TP40002528-SW2

the long answer is: this is not about relocations but about the code  
model (see the next section in the documentation above).
as long as the compiler takes care of loading data from elsewhere, you  
don't have to care. referencing data directly from inline assembly is  
much trickier, because you have to take care of the loading process  
yourself. simple data values that are not more than 2gb away from the  
instruction pointer are easy to load/store - just use (%rip).  
everything else has to go through a global offset table, which is  
again local and addressed rip-relative. i have no idea why apple chose  
this implementation - maybe just to save on complexity. local and pic  
addressing cover most use cases, so why bother?

>>>> The rest of the code that doesn't compile in 64-bits is liba52,  
>>>> which
>>>> in a way should not matter much since FFmpeg has experimental have
>>>> full AC3 support...

actually, there is more:
mp3lib/decode_mmx.c
but if i'm not mistaken, the fixes for this file are simple.
there might be even more places to fix. so far, i've identified liba52/ 
imdct.c, liba52/resample_mmx.c, libmpcodecs/vf_fspp.c and mp3lib/ 
decode_mmx.c.
here's a patch that should be portable (didn't test it yet though):
--- mp3lib/decode_mmx.c	2008-12-04 03:26:17.000000000 +0100
+++ mp3lib/decode_mmx.c.edit	2008-12-15 16:43:02.000000000 +0100
@@ -258,2 +258,2 @@
-	"pand   "MANGLE(one_null)", %%mm1\n\t"
-	"pand   "MANGLE(null_one)", %%mm0\n\t"
+	"pand   %4, %%mm1\n\t"
+	"pand   %5, %%mm0\n\t"
@@ -334,2 +334,2 @@
-	"pand   "MANGLE(one_null)", %%mm1\n\t"
-	"pand   "MANGLE(null_one)", %%mm0\n\t"
+	"pand   %4, %%mm1\n\t"
+	"pand   %5, %%mm0\n\t"
@@ -367 +367 @@
-	:
+	:"m"(one_null), "m"(null_one)

>>> FFmpeg AC3 support is unusable unless someone implements support for
>>> avparser (unless you don't care about ac3 in MPEG, on DVDs and raw  
>>> AC3).
>>
>> Is that a lot of work?
>
> No idea, probably not so much.

if the quality/speed of the ffmpeg decoder is as good or better, i  
don't see why it shouldn't be used.
according to this -> http://lists.mplayerhq.hu/pipermail/mplayer-users/2007-August/068525.html 
  post, this is probably the case by now.

a note about vf_fspp and -O2: odd. in vf_fspp.c, MANGLEs are used, and  
i don't see why they should suddenly work with less c optimisation.  
did you check the generated assembly?