[PATCH] Replaced deprecated QuickDraw calls in vo_quartz
hello. when compiling mplayer against a recent (10.4+) sdk, gcc spits out quite a few deprecation warnings in the vo_quartz output module. the respective functions are part of quickdraw, which is recommended not to be used any more, and not supported at all when compiling for 64bit. i tried to fix these by replacing them with quartz calls. as far as i can see, the modifications work, the compiler warnings are gone and there are no performance issues. please review the patch and provide feedback. i know there's also the cocoa based vo_macosx module, but since both are around, they should both be free from legacy code, shouldn't they? :) i think i used one function marked as 10.1+, but the rest is marked to be available even in 10.0, if people still want to build against that. best regards, oni
Hello, On Thu, Oct 2, 2008 at 2:27 PM, onitake <onitake@gmail.com> wrote:
hello.
when compiling mplayer against a recent (10.4+) sdk, gcc spits out quite a few deprecation warnings in the vo_quartz output module. the respective functions are part of quickdraw, which is recommended not to be used any more, and not supported at all when compiling for 64bit.
Your code does allow to get rid of warnings here on 10.5.5, MacIntel, 32 bits mode, but there are still lots of warnings and errors when compiling in 64 bits mode: gcc -arch x86_64 -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -pipe -ffast-math -fomit-frame-pointer -mdynamic-no-pic -falign-loops=16 -shared-libgcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/local/include -I/usr/X11/include -c -o libvo/vo_quartz.o libvo/vo_quartz.c libvo/vo_quartz.c:57: error: syntax error before 'seqId' libvo/vo_quartz.c:57: warning: type defaults to 'int' in declaration of 'seqId' libvo/vo_quartz.c:57: warning: data definition has no type or storage class libvo/vo_quartz.c:58: error: syntax error before 'image_qtcodec' libvo/vo_quartz.c:58: warning: type defaults to 'int' in declaration of 'image_qtcodec' libvo/vo_quartz.c:58: warning: data definition has no type or storage class libvo/vo_quartz.c:59: error: syntax error before '*' token libvo/vo_quartz.c:59: warning: type defaults to 'int' in declaration of 'P' libvo/vo_quartz.c:59: warning: data definition has no type or storage class libvo/vo_quartz.c:62: error: syntax error before 'ImageDescriptionHandle' libvo/vo_quartz.c:62: warning: no semicolon at end of struct or union libvo/vo_quartz.c:67: error: syntax error before '}' token libvo/vo_quartz.c:67: warning: type defaults to 'int' in declaration of 'yuv_qt_stuff' libvo/vo_quartz.c:67: warning: data definition has no type or storage class libvo/vo_quartz.c:68: error: syntax error before 'matrix' libvo/vo_quartz.c:68: warning: type defaults to 'int' in declaration of 'matrix' libvo/vo_quartz.c:68: warning: data definition has no type or storage class libvo/vo_quartz.c: In function 'draw_alpha': libvo/vo_quartz.c:208: error: request for member 'componentInfoY' in something not a structure or union libvo/vo_quartz.c: In function 'KeyEventHandler': libvo/vo_quartz.c:251: warning: implicit declaration of function 'SetWindowAlpha' libvo/vo_quartz.c: In function 'MouseEventHandler': libvo/vo_quartz.c:299: warning: implicit declaration of function 'FindWindow' libvo/vo_quartz.c:318: warning: implicit declaration of function 'GetWindowPortBounds' libvo/vo_quartz.c:347: warning: implicit declaration of function 'ResizeWindow' libvo/vo_quartz.c:352: warning: implicit declaration of function 'MenuSelect' libvo/vo_quartz.c:353: warning: implicit declaration of function 'HiliteMenu' libvo/vo_quartz.c: In function 'WindowEventHandler': libvo/vo_quartz.c:415: warning: implicit declaration of function 'SizeWindow' libvo/vo_quartz.c:445: warning: implicit declaration of function 'CheckMenuItem' libvo/vo_quartz.c:497: warning: implicit declaration of function 'GetWindowBounds' libvo/vo_quartz.c: In function 'quartz_CreateWindow': libvo/vo_quartz.c:558: warning: implicit declaration of function 'ClearMenuBar' libvo/vo_quartz.c:561: warning: implicit declaration of function 'CreateStandardWindowMenu' libvo/vo_quartz.c:562: warning: implicit declaration of function 'InsertMenu' libvo/vo_quartz.c:565: warning: implicit declaration of function 'CreateNewMenu' libvo/vo_quartz.c:567: warning: implicit declaration of function 'SetMenuTitleWithCFString' libvo/vo_quartz.c:569: warning: implicit declaration of function 'AppendMenuItemTextWithCFString' libvo/vo_quartz.c:570: warning: implicit declaration of function 'SetMenuItemCommandKey' libvo/vo_quartz.c:589: warning: implicit declaration of function 'SetMenuItemHierarchicalMenu' libvo/vo_quartz.c:600: warning: implicit declaration of function 'GetMenuID' libvo/vo_quartz.c:602: warning: implicit declaration of function 'DrawMenuBar' libvo/vo_quartz.c:605: warning: implicit declaration of function 'CreateNewWindow' libvo/vo_quartz.c:607: warning: implicit declaration of function 'CreateWindowGroup' libvo/vo_quartz.c:608: warning: implicit declaration of function 'SetWindowGroup' libvo/vo_quartz.c:613: warning: implicit declaration of function 'SetWindowTitleWithCFString' libvo/vo_quartz.c:618: warning: implicit declaration of function 'GetApplicationEventTarget' libvo/vo_quartz.c:618: warning: passing argument 1 of 'InstallEventHandler' makes pointer from integer without a cast libvo/vo_quartz.c:619: warning: passing argument 1 of 'InstallEventHandler' makes pointer from integer without a cast libvo/vo_quartz.c:620: warning: implicit declaration of function 'GetWindowEventTarget' libvo/vo_quartz.c:620: warning: passing argument 1 of 'InstallEventHandler' makes pointer from integer without a cast libvo/vo_quartz.c: In function 'config': libvo/vo_quartz.c:703: warning: implicit declaration of function 'QDBeginCGContext' libvo/vo_quartz.c:703: warning: implicit declaration of function 'GetWindowPort' libvo/vo_quartz.c:705: warning: implicit declaration of function 'QDEndCGContext' libvo/vo_quartz.c:709: warning: implicit declaration of function 'HideWindow' libvo/vo_quartz.c:710: warning: implicit declaration of function 'ChangeWindowAttributes' libvo/vo_quartz.c:749: warning: implicit declaration of function 'EnterMovies' libvo/vo_quartz.c:762: warning: implicit declaration of function 'SetIdentityMatrix' libvo/vo_quartz.c:766: warning: implicit declaration of function 'ScaleMatrix' libvo/vo_quartz.c:769: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:769: error: 'ImageDescriptionHandle' undeclared (first use in this function) libvo/vo_quartz.c:769: error: (Each undeclared identifier is reported only once libvo/vo_quartz.c:769: error: for each function it appears in.) libvo/vo_quartz.c:769: error: syntax error before 'NewHandleClear' libvo/vo_quartz.c:771: error: request for member 'extension_colr' in something not a structure or union libvo/vo_quartz.c:771: error: 'NCLCColorInfoImageDescriptionExtension' undeclared (first use in this function) libvo/vo_quartz.c:772: error: syntax error before ')' token libvo/vo_quartz.c:772: error: request for member 'extension_colr' in something not a structure or union libvo/vo_quartz.c:772: error: 'kVideoColorInfoImageDescriptionExtensionType' undeclared (first use in this function) libvo/vo_quartz.c:773: error: syntax error before ')' token libvo/vo_quartz.c:773: error: request for member 'extension_colr' in something not a structure or union libvo/vo_quartz.c:774: error: syntax error before ')' token libvo/vo_quartz.c:774: error: request for member 'extension_colr' in something not a structure or union libvo/vo_quartz.c:775: error: syntax error before ')' token libvo/vo_quartz.c:775: error: request for member 'extension_colr' in something not a structure or union libvo/vo_quartz.c:777: error: request for member 'extension_fiel' in something not a structure or union libvo/vo_quartz.c:777: error: 'FieldInfoImageDescriptionExtension' undeclared (first use in this function) libvo/vo_quartz.c:778: error: syntax error before ')' token libvo/vo_quartz.c:778: error: request for member 'extension_fiel' in something not a structure or union libvo/vo_quartz.c:779: error: syntax error before ')' token libvo/vo_quartz.c:779: error: request for member 'extension_fiel' in something not a structure or union libvo/vo_quartz.c:781: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:781: error: 'CleanApertureImageDescriptionExtension' undeclared (first use in this function) libvo/vo_quartz.c:782: error: syntax error before ')' token libvo/vo_quartz.c:782: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:783: error: syntax error before ')' token libvo/vo_quartz.c:783: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:784: error: syntax error before ')' token libvo/vo_quartz.c:784: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:785: error: syntax error before ')' token libvo/vo_quartz.c:785: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:786: error: syntax error before ')' token libvo/vo_quartz.c:786: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:787: error: syntax error before ')' token libvo/vo_quartz.c:787: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:788: error: syntax error before ')' token libvo/vo_quartz.c:788: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:789: error: syntax error before ')' token libvo/vo_quartz.c:789: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:791: error: request for member 'extension_pasp' in something not a structure or union libvo/vo_quartz.c:791: error: 'PixelAspectRatioImageDescriptionExtension' undeclared (first use in this function) libvo/vo_quartz.c:792: error: syntax error before ')' token libvo/vo_quartz.c:792: error: request for member 'extension_pasp' in something not a structure or union libvo/vo_quartz.c:793: error: syntax error before ')' token libvo/vo_quartz.c:793: error: request for member 'extension_pasp' in something not a structure or union libvo/vo_quartz.c:795: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:795: error: 'ImageDescription' undeclared (first use in this function) libvo/vo_quartz.c:796: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:797: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:798: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:799: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:800: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:801: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:802: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:803: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:804: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:805: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:805: error: 'codecLosslessQuality' undeclared (first use in this function) libvo/vo_quartz.c:806: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:807: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:808: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:809: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:811: warning: implicit declaration of function 'AddImageDescriptionExtension' libvo/vo_quartz.c:811: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:811: error: request for member 'extension_colr' in something not a structure or union libvo/vo_quartz.c:811: error: 'kColorInfoImageDescriptionExtension' undeclared (first use in this function) libvo/vo_quartz.c:817: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:817: error: request for member 'extension_fiel' in something not a structure or union libvo/vo_quartz.c:817: error: 'kFieldInfoImageDescriptionExtension' undeclared (first use in this function) libvo/vo_quartz.c:823: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:823: error: request for member 'extension_clap' in something not a structure or union libvo/vo_quartz.c:823: error: 'kCleanApertureImageDescriptionExtension' undeclared (first use in this function) libvo/vo_quartz.c:829: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:829: error: request for member 'extension_pasp' in something not a structure or union libvo/vo_quartz.c:837: error: 'PlanarPixmapInfoYUV420' undeclared (first use in this function) libvo/vo_quartz.c:843: error: request for member 'componentInfoY' in something not a structure or union libvo/vo_quartz.c:844: error: request for member 'componentInfoCb' in something not a structure or union libvo/vo_quartz.c:844: error: request for member 'componentInfoY' in something not a structure or union libvo/vo_quartz.c:845: error: request for member 'componentInfoCr' in something not a structure or union libvo/vo_quartz.c:845: error: request for member 'componentInfoCb' in something not a structure or union libvo/vo_quartz.c:846: error: request for member 'componentInfoY' in something not a structure or union libvo/vo_quartz.c:847: error: request for member 'componentInfoCb' in something not a structure or union libvo/vo_quartz.c:848: error: request for member 'componentInfoCr' in something not a structure or union libvo/vo_quartz.c:857: warning: implicit declaration of function 'DecompressSequenceBeginS' libvo/vo_quartz.c:858: error: request for member 'desc' in something not a structure or union libvo/vo_quartz.c:870: error: 'bestSpeedCodec' undeclared (first use in this function) libvo/vo_quartz.c:882: warning: implicit declaration of function 'RepositionWindow' libvo/vo_quartz.c:883: warning: implicit declaration of function 'ShowWindow' libvo/vo_quartz.c:895: warning: implicit declaration of function 'SetWindowGroupLevel' libvo/vo_quartz.c: In function 'flip_page': libvo/vo_quartz.c:951: error: 'CodecFlags' undeclared (first use in this function) libvo/vo_quartz.c:951: error: syntax error before 'flags' libvo/vo_quartz.c:952: warning: implicit declaration of function 'DecompressSequenceFrameWhen' libvo/vo_quartz.c:956: error: 'flags' undeclared (first use in this function) libvo/vo_quartz.c:1020: warning: implicit declaration of function 'UpdateSystemActivity' libvo/vo_quartz.c:1020: error: 'UsrActivity' undeclared (first use in this function) libvo/vo_quartz.c: In function 'draw_slice': libvo/vo_quartz.c:1031: error: request for member 'componentInfoY' in something not a structure or union libvo/vo_quartz.c:1034: error: request for member 'componentInfoCb' in something not a structure or union libvo/vo_quartz.c:1035: error: request for member 'componentInfoCr' in something not a structure or union libvo/vo_quartz.c:1039: error: request for member 'componentInfoY' in something not a structure or union libvo/vo_quartz.c:1042: error: request for member 'componentInfoCr' in something not a structure or union libvo/vo_quartz.c:1043: error: request for member 'componentInfoCb' in something not a structure or union libvo/vo_quartz.c: In function 'query_format': libvo/vo_quartz.c:1077: error: 'kMpegYUV420CodecType' undeclared (first use in this function) libvo/vo_quartz.c:1083: error: 'kComponentVideoUnsigned' undeclared (first use in this function) libvo/vo_quartz.c:1089: error: 'k422YpCbCr8CodecType' undeclared (first use in this function) libvo/vo_quartz.c: In function 'uninit': libvo/vo_quartz.c:1110: warning: implicit declaration of function 'CDSequenceEnd' libvo/vo_quartz.c:1122: warning: implicit declaration of function 'ShowMenuBar' libvo/vo_quartz.c: In function 'get_yuv_image': libvo/vo_quartz.c:1198: error: request for member 'componentInfoY' in something not a structure or union libvo/vo_quartz.c:1205: error: request for member 'componentInfoCb' in something not a structure or union libvo/vo_quartz.c:1206: error: request for member 'componentInfoCr' in something not a structure or union libvo/vo_quartz.c:1213: error: request for member 'componentInfoCr' in something not a structure or union libvo/vo_quartz.c:1214: error: request for member 'componentInfoCb' in something not a structure or union libvo/vo_quartz.c: In function 'window_resized': libvo/vo_quartz.c:1347: warning: implicit declaration of function 'TranslateMatrix' libvo/vo_quartz.c:1351: warning: implicit declaration of function 'SetDSequenceMatrix' libvo/vo_quartz.c: In function 'window_fullscreen': libvo/vo_quartz.c:1406: warning: cast from pointer to integer of different size libvo/vo_quartz.c:1406: warning: cast from pointer to integer of different size libvo/vo_quartz.c:1432: warning: implicit declaration of function 'MoveWindow' Note that this isn't that much of a problem, as I much prefer to first fix deprecation warnings, then addressing 64-bits compilation issues.
i tried to fix these by replacing them with quartz calls. as far as i can see, the modifications work, the compiler warnings are gone and there are no performance issues. please review the patch and provide feedback.
I can't really comment on the code as I have no previous knowledge of MacOSX multimedia API, but Nicolas Plourde (in CC) should.
i know there's also the cocoa based vo_macosx module, but since both are around, they should both be free from legacy code, shouldn't they? :)
Yep. But vo_macosx doesn't compile on 64 bits mode either! gcc -arch x86_64 -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -pipe -ffast-math -fomit-frame-pointer -mdynamic-no-pic -falign-loops=16 -shared-libgcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/local/include -I/usr/X11/include -c -o libvo/vo_macosx.o libvo/vo_macosx.m libvo/vo_macosx.m: In function '-[MPlayerOpenGLView render]': libvo/vo_macosx.m:778: warning: implicit declaration of function 'UpdateSystemActivity' libvo/vo_macosx.m:778: error: 'UsrActivity' undeclared (first use in this function) libvo/vo_macosx.m:778: error: (Each undeclared identifier is reported only once libvo/vo_macosx.m:778: error: for each function it appears in.) make: *** [libvo/vo_macosx.o] Error 1
i think i used one function marked as 10.1+, but the rest is marked to be available even in 10.0, if people still want to build against that.
That's definitely not a problem. We currently only support 10.4 and 10.5 as compile host, and probably 10.3 only though "cross-compilation" from a 10.4-5 devel/compile machine. Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
Your code does allow to get rid of warnings here on 10.5.5, MacIntel, 32 bits mode,
glad to hear that. i don't have a core2duo mac at hand, so i couldn't test.
but there are still lots of warnings and errors when compiling in 64 bits mode:
libvo/vo_quartz.c:57: error: syntax error before 'seqId' libvo/vo_quartz.c:58: error: syntax error before 'image_qtcodec' libvo/vo_quartz.c:59: error: syntax error before '*' token libvo/vo_quartz.c:62: error: syntax error before 'ImageDescriptionHandle' libvo/vo_quartz.c:68: error: syntax error before 'matrix'
this is odd. these data types are part of quicktime and not deprecated. also, there is an unconditional include of QuickTime.h.
libvo/vo_quartz.c:299: warning: implicit declaration of function 'FindWindow' libvo/vo_quartz.c:347: warning: implicit declaration of function 'ResizeWindow' libvo/vo_quartz.c:352: warning: implicit declaration of function 'MenuSelect' libvo/vo_quartz.c:353: warning: implicit declaration of function 'HiliteMenu' ......
those are all part of the carbon api. it looks like apple wants to get rid of it eventually, as carbon isn't supported in 64bit mode. or they just didn't have the resources to port it yet.
Note that this isn't that much of a problem, as I much prefer to first fix deprecation warnings, then addressing 64-bits compilation issues.
I can't really comment on the code as I have no previous knowledge of MacOSX multimedia API, but Nicolas Plourde (in CC) should.
thanks, i'll cc him too.
Yep. But vo_macosx doesn't compile on 64 bits mode either!
libvo/vo_macosx.m: In function '-[MPlayerOpenGLView render]': libvo/vo_macosx.m:778: warning: implicit declaration of function 'UpdateSystemActivity' libvo/vo_macosx.m:778: error: 'UsrActivity' undeclared (first use in this function) libvo/vo_macosx.m:778: error: (Each undeclared identifier is reported only once libvo/vo_macosx.m:778: error: for each function it appears in.) make: *** [libvo/vo_macosx.o] Error 1
looking into this now. the vo_macosx uses cocoa for the window manager stuff, corevideo for frame decoding plus... opengl for the rendering? interesting approach. the respective code looks like it was copy-pasted from vo_quartz. let me find a different method to disable the screensaver. instead UsrActivity and the SetSystemUIMode further below, shouldn't CGDisplayCapture and CGDisplaySwitchToMode do the trick? starting from 10.5, there's also the new power management api. IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep, kIOPMAssertionLevelOn, &assId) could work, but i don't know if it disables the screensaver.
That's definitely not a problem. We currently only support 10.4 and 10.5 as compile host, and probably 10.3 only though "cross-compilation" from a 10.4-5 devel/compile machine.
i'll run a few tests and try different sdks. i won't be able to test on 64bit, but i can at least do a 64bit crosscompile. by the way, in vo_quartz.c, there's this fragment of code: #if !defined (CONFIG_MACOSX_FINDER) || !defined (CONFIG_SDL) //this chunk of code is heavily based off SDL_macosx.m from SDL //it uses an Apple private function to request foreground operation { void CPSEnableForegroundOperation(ProcessSerialNumber* psn); ProcessSerialNumber myProc, frProc; Boolean sameProc; if (GetFrontProcess(&frProc) == noErr) { if (GetCurrentProcess(&myProc) == noErr) { if (SameProcess(&frProc, &myProc, &sameProc) == noErr && !sameProc) { CPSEnableForegroundOperation(&myProc); } SetFrontProcess(&myProc); } } } #endif i remember seeing something similar in the example SDLmain.m that comes with sdl (and it also says in the comments it's from there). i patched out the private api call, but it still bothers me a bit. isn't there a better way to make a bundleless ui application become front? maybe via [NSApp activateIgnoringOtherApps:]? while googling, i stumbled upon this: http://lists.apple.com/archives/cocoa-dev/2008/Aug/msg00117.html thanks for your feedback!
Hello, On Fri, Oct 3, 2008 at 12:57 PM, Gregor Riepl <onitake@gmail.com> wrote:
but there are still lots of warnings and errors when compiling in 64 bits mode:
libvo/vo_quartz.c:57: error: syntax error before 'seqId' libvo/vo_quartz.c:58: error: syntax error before 'image_qtcodec' libvo/vo_quartz.c:59: error: syntax error before '*' token libvo/vo_quartz.c:62: error: syntax error before 'ImageDescriptionHandle' libvo/vo_quartz.c:68: error: syntax error before 'matrix'
this is odd. these data types are part of quicktime and not deprecated. also, there is an unconditional include of QuickTime.h.
libvo/vo_quartz.c:299: warning: implicit declaration of function 'FindWindow' libvo/vo_quartz.c:347: warning: implicit declaration of function 'ResizeWindow' libvo/vo_quartz.c:352: warning: implicit declaration of function 'MenuSelect' libvo/vo_quartz.c:353: warning: implicit declaration of function 'HiliteMenu' ......
those are all part of the carbon api. it looks like apple wants to get rid of it eventually, as carbon isn't supported in 64bit mode. or they just didn't have the resources to port it yet.
To be best of my knowledge, the position of Apple regarding Carbon is that won't ever be supported in 64bits mode. Cocoa is the way to go if you want your app to be 64-bits compatible. The good thing is that Cocoa already supports (and for several MacOSX) what should be needed to implement a fast video out driver for Darwin. Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
Hello, Guillaume POIRIER wrote: [..]
The good thing is that Cocoa already supports (and for several MacOSX) what should be needed to implement a fast video out driver for Darwin
I meant to say: "To the best of my knowledge, Cocoa has supported for several MacOSX releases what is needed to implement a fast video out driver for Darwin". Sorry for the confusion. Guillaume
Sorry for the confusion.
your first statement was perfectly intelligible. :) anyway, i dug up a two things. first, UpdateSystemActivity is nowhere mentioned as being deprecated or not available. it's even in the CoreServices/OSServices framework for all 4 supported architectures. the only problem is that apple inserted a #if !__LP64__ #ifndef __POWER__ #include <OSServices/Power.h> #endif into /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OSServices.h, which makes the compiler fail. the linker would in fact succeed. i filed a bug (radar #6267445) against this. second, up from 10.5, there is a replacement for this function: IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep, kIOPMAssertionLevelOn, &assertionID); the problem is that this only disables display power management and not the screensaver. i have yet to find a good way to do this. people suggest defaults write com.apple.screensaver write idleTime 0 but this looks like a terrible hack to me and it seems setting it back to a positive number doesn't turn the screensaver back on again. here's an updated patch. i don't suggest applying it yet, as it switches to IOPMAssertion when compiling for 10.5, and the screensaver is still on. but you can test if it works on x86_64, if you like. i hope apple helps with a permanent solution.
Hello, On Fri, Oct 3, 2008 at 5:49 PM, Gregor Riepl <onitake@gmail.com> wrote:
here's an updated patch. i don't suggest applying it yet, as it switches to IOPMAssertion when compiling for 10.5, and the screensaver is still on. but you can test if it works on x86_64, if you like.
I tested your patch on 10.4.11/PPC, and it doesn't compile: cc -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -mcpu=970 -mtune=970 -pipe -ffast-math -fomit-frame-pointer -maltivec -mabi=altivec -mdynamic-no-pic -falign-loops=16 -shared-libgcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/opt/local/include/ -I/usr/local/include -I/usr/X11R6/include -I/opt/local/include/freetype2 -I/opt/local/include -c -o libvo/vo_macosx.o libvo/vo_macosx.m In file included from libvo/vo_macosx.m:9: libvo/vo_macosx.h:69: error: parse error before 'IOPMAssertionID' libvo/vo_macosx.m: In function '-[MPlayerOpenGLView fullscreen:]': libvo/vo_macosx.m:827: warning: implicit declaration of function 'IOPMAssertionCreate' libvo/vo_macosx.m:827: error: 'kIOPMAssertionTypeNoDisplaySleep' undeclared (first use in this function) libvo/vo_macosx.m:827: error: (Each undeclared identifier is reported only once libvo/vo_macosx.m:827: error: for each function it appears in.) libvo/vo_macosx.m:827: error: 'kIOPMAssertionLevelOn' undeclared (first use in this function) libvo/vo_macosx.m:827: error: 'assertionID' undeclared (first use in this function) libvo/vo_macosx.m:866: warning: implicit declaration of function 'IOPMAssertionRelease' make: *** [libvo/vo_macosx.o] Error 1 I do understand that your patch is not supposed to be finished yet, but I'd like to remind you that MPlayer should be kept backward compatible with 10.4 since Tiger packs everything that is needed for MPlayer to work well, and Tiger is also the last OS with which PPC machines have been shipped. I don't want to break support for that. Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
I tested your patch on 10.4.11/PPC, and it doesn't compile:
....
I do understand that your patch is not supposed to be finished yet, but I'd like to remind you that MPlayer should be kept backward compatible with 10.4 since Tiger packs everything that is needed for MPlayer to work well, and Tiger is also the last OS with which PPC machines have been shipped. I don't want to break support for that.
thanks for your feedback. i assumed #if MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_5 guards against exactly this. the existing code is still in, only when targeting 10.5+, the new IOPM api will be used. the only problem with this is that simply changing the sdk doesn't suffice. you need to use the gcc parameter -mmacosx-version-min=10.4 or 10.3 too. the following works: cc -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after- statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant- decls -O4 -pipe -ffast-math -fomit-frame-pointer -mdynamic-no-pic - falign-loops=16 -shared-libgcc -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/local/include - I/usr/X11/include -I/usr/local/include/freetype2 -I/usr/local/include - c -o libvo/vo_macosx.o libvo/vo_macosx.m -isysroot /Developer/SDKs/ MacOSX10.4u.sdk -mmacosx-version-min=10.4 -arch ppc -faltivec i'm not sure how to remedy this. is there a better way to check for the current sdk at compile time? or should the version-min parameter be added via the configure script?
2008/10/3 Gregor Riepl <onitake@gmail.com>:
Sorry for the confusion.
your first statement was perfectly intelligible. :)
anyway, i dug up a two things. first, UpdateSystemActivity is nowhere mentioned as being deprecated or not available. it's even in the CoreServices/OSServices framework for all 4 supported architectures. the only problem is that apple inserted a #if !__LP64__ #ifndef __POWER__ #include <OSServices/Power.h> #endif into /System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h, which makes the compiler fail. the linker would in fact succeed. i filed a bug (radar #6267445) against this.
how about manually add it into head of our source file? #ifndef __POWER__ #include <OSServices/Power.h> #endif -- Ulion
how about manually add it into head of our source file?
#ifndef __POWER__ #include <OSServices/Power.h> #endif
since apple didn't respond to my bug report, i implemented your suggestion for both vo_macosx and vo_quartz. in case they do reply, i'll keep a patch of the IOPMAssertion method around. as i heard, your ppc64 died recently, guillaume, so i'm asking anyone with a 64bit 10.5 or 10.4 machine to test. vo_quartz seems to be unworkable on 64bit, but vo_macosx should be ok now if i didn't miss anything. i also have a question about #if !defined (CONFIG_MACOSX_FINDER) || !defined (CONFIG_SDL) is this really meant that way? only skip the code if both finder support and vo_sdl are enabled? i also wonder if the TransformProcessType() below is 64bit compatible (i already replaced the deprecated CPSEnableForegroundOperation with a TransformProcessType). it looks ok for vo_quartz, but there should be a better way for vo_macosx, imho. nicolas: thanks for your reply. what did you fix in the patch? i diff'd it and only saw a few cosmetic changes.
Hello, On Mon, Oct 27, 2008 at 7:54 PM, Gregor Riepl <onitake@gmail.com> wrote:
how about manually add it into head of our source file?
#ifndef __POWER__ #include <OSServices/Power.h> #endif
since apple didn't respond to my bug report, i implemented your suggestion for both vo_macosx and vo_quartz. in case they do reply, i'll keep a patch of the IOPMAssertion method around.
as i heard, your ppc64 died recently, guillaume, so i'm asking anyone with a 64bit 10.5 or 10.4 machine to test.
Luckily, I do have a MacBook Pro with Leopard on it: Here's MacOSX VO: gcc -arch x86_64 -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -pipe -ffast-math -fomit-frame-pointer -mdynamic-no-pic -falign-loops=16 -shared-libgcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/local/include -I/usr/X11/include -c -o libvo/vo_macosx.o libvo/vo_macosx.m libvo/vo_macosx.m:17:30: error: OSServices/Power.h: No such file or directory libvo/vo_macosx.m: In function '-[MPlayerOpenGLView render]': libvo/vo_macosx.m:783: warning: implicit declaration of function 'UpdateSystemActivity' libvo/vo_macosx.m:783: error: 'UsrActivity' undeclared (first use in this function) libvo/vo_macosx.m:783: error: (Each undeclared identifier is reported only once libvo/vo_macosx.m:783: error: for each function it appears in.) make: *** [libvo/vo_macosx.o] Error 1 So unfortunately, it still fails :-(
vo_quartz seems to be unworkable on 64bit,
Yep.
but vo_macosx should be ok now if i didn't miss anything.
Unfortunately still not :-(
i also have a question about #if !defined (CONFIG_MACOSX_FINDER) || !defined (CONFIG_SDL) is this really meant that way? only skip the code if both finder support and vo_sdl are enabled? i also wonder if the TransformProcessType() below is 64bit compatible (i already replaced the deprecated CPSEnableForegroundOperation with a TransformProcessType). it looks ok for vo_quartz, but there should be a better way for vo_macosx, imho.
I don't have an answer for that one though :-( Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
here's an updated patch that should work on x86_64 and ppc64. i also modified configure, so support for coreaudio, corevideo and quartz/carbon support is checked separately. if the carbon test fails (true for 64bit mode), vo_quartz will not be built, but vo_macosx and ao_macosx stay enabled.
Hello, On Tue, Oct 28, 2008 at 6:36 PM, Gregor Riepl <onitake@gmail.com> wrote:
here's an updated patch that should work on x86_64 and ppc64. i also modified configure, so support for coreaudio, corevideo and quartz/carbon support is checked separately. if the carbon test fails (true for 64bit mode), vo_quartz will not be built, but vo_macosx and ao_macosx stay enabled.
We're getting much closer to getting MPlayer compiled. After forcing arch to x86_64, and running: CC="gcc -arch x86_64" ./configure --disable-liba52-internal ; make -j3 compilation ends at the linking stage: gcc -arch x86_64 -o mplayer mplayer.o m_property.o mp_fifo.o mp_msg.o mixer.o parser-mpcmd.o command.o input/input.o libao2/audio_out.o libao2/ao_mpegpes.o libao2/ao_null.o libao2/ao_pcm.o libao2/ao_macosx.o libao2/ao_openal.o libvo/aspect.o libvo/geometry.o libvo/spuenc.o libvo/video_out.o libvo/vo_mpegpes.o libvo/vo_null.o libvo/vo_macosx.o libvo/vo_tga.o libvo/vo_md5sum.o libvo/vo_yuv4mpeg.o libvo/vo_pnm.o input/ar.o asxparser.o codec-cfg.o cpudetect.o edl.o find_sub.o get_path.o m_config.o m_option.o m_struct.o mpcommon.o parser-cfg.o playtree.o playtreeparser.o spudec.o sub_cc.o subopt-helper.o subreader.o vobsub.o libaf/af.o libaf/af_center.o libaf/af_channels.o libaf/af_comp.o libaf/af_delay.o libaf/af_dummy.o libaf/af_equalizer.o libaf/af_extrastereo.o libaf/af_format.o libaf/af_gate.o libaf/af_hrtf.o libaf/af_karaoke.o libaf/af_pan.o libaf/af_resample.o libaf/af_scaletempo.o libaf/af_sinesuppress.o libaf/af_sub.o libaf/af_surround.o libaf/af_sweep.o libaf/af_tools.o libaf/af_volnorm.o libaf/af_volume.o libaf/filter.o libaf/format.o libaf/reorder_ch.o libaf/window.o libmpcodecs/ad.o libmpcodecs/ad_alaw.o libmpcodecs/ad_dk3adpcm.o libmpcodecs/ad_dvdpcm.o libmpcodecs/ad_hwmpa.o libmpcodecs/ad_imaadpcm.o libmpcodecs/ad_msadpcm.o libmpcodecs/ad_msgsm.o libmpcodecs/ad_pcm.o libmpcodecs/dec_audio.o libmpcodecs/dec_video.o libmpcodecs/img_format.o libmpcodecs/mp_image.o libmpcodecs/native/nuppelvideo.o libmpcodecs/native/rtjpegn.o libmpcodecs/native/xa_gsm.o libmpcodecs/pullup.o libmpcodecs/vd.o libmpcodecs/vd_hmblck.o libmpcodecs/vd_lzo.o libmpcodecs/vd_mpegpes.o libmpcodecs/vd_mtga.o libmpcodecs/vd_null.o libmpcodecs/vd_nuv.o libmpcodecs/vd_raw.o libmpcodecs/vd_sgi.o libmpcodecs/vf.o libmpcodecs/vf_1bpp.o libmpcodecs/vf_2xsai.o libmpcodecs/vf_blackframe.o libmpcodecs/vf_boxblur.o libmpcodecs/vf_crop.o libmpcodecs/vf_cropdetect.o libmpcodecs/vf_decimate.o libmpcodecs/vf_delogo.o libmpcodecs/vf_denoise3d.o libmpcodecs/vf_detc.o libmpcodecs/vf_dint.o libmpcodecs/vf_divtc.o libmpcodecs/vf_down3dright.o libmpcodecs/vf_dsize.o libmpcodecs/vf_dvbscale.o libmpcodecs/vf_eq.o libmpcodecs/vf_eq2.o libmpcodecs/vf_expand.o libmpcodecs/vf_field.o libmpcodecs/vf_fil.o libmpcodecs/vf_filmdint.o libmpcodecs/vf_flip.o libmpcodecs/vf_format.o libmpcodecs/vf_framestep.o libmpcodecs/vf_halfpack.o libmpcodecs/vf_harddup.o libmpcodecs/vf_hqdn3d.o libmpcodecs/vf_hue.o libmpcodecs/vf_il.o libmpcodecs/vf_ilpack.o libmpcodecs/vf_ivtc.o libmpcodecs/vf_kerndeint.o libmpcodecs/vf_mirror.o libmpcodecs/vf_noformat.o libmpcodecs/vf_noise.o libmpcodecs/vf_ow.o libmpcodecs/vf_palette.o libmpcodecs/vf_perspective.o libmpcodecs/vf_phase.o libmpcodecs/vf_pp7.o libmpcodecs/vf_pullup.o libmpcodecs/vf_rectangle.o libmpcodecs/vf_remove_logo.o libmpcodecs/vf_rgb2bgr.o libmpcodecs/vf_rgbtest.o libmpcodecs/vf_rotate.o libmpcodecs/vf_sab.o libmpcodecs/vf_scale.o libmpcodecs/vf_smartblur.o libmpcodecs/vf_softpulldown.o libmpcodecs/vf_softskip.o libmpcodecs/vf_swapuv.o libmpcodecs/vf_telecine.o libmpcodecs/vf_test.o libmpcodecs/vf_tfields.o libmpcodecs/vf_tile.o libmpcodecs/vf_tinterlace.o libmpcodecs/vf_unsharp.o libmpcodecs/vf_vo.o libmpcodecs/vf_yadif.o libmpcodecs/vf_yuvcsp.o libmpcodecs/vf_yuy2.o libmpcodecs/vf_yvu9.o libmpdemux/aac_hdr.o libmpdemux/asfheader.o libmpdemux/aviheader.o libmpdemux/aviprint.o libmpdemux/demuxer.o libmpdemux/demux_aac.o libmpdemux/demux_asf.o libmpdemux/demux_audio.o libmpdemux/demux_avi.o libmpdemux/demux_demuxers.o libmpdemux/demux_film.o libmpdemux/demux_fli.o libmpdemux/demux_lmlm4.o libmpdemux/demux_mf.o libmpdemux/demux_mkv.o libmpdemux/demux_mov.o libmpdemux/demux_mpg.o libmpdemux/demux_nsv.o libmpdemux/demux_nuv.o libmpdemux/demux_pva.o libmpdemux/demux_rawaudio.o libmpdemux/demux_rawvideo.o libmpdemux/demux_realaud.o libmpdemux/demux_real.o libmpdemux/demux_roq.o libmpdemux/demux_smjpeg.o libmpdemux/demux_ts.o libmpdemux/demux_ty.o libmpdemux/demux_ty_osd.o libmpdemux/demux_viv.o libmpdemux/demux_vqf.o libmpdemux/demux_y4m.o libmpdemux/ebml.o libmpdemux/extension.o libmpdemux/mf.o libmpdemux/mp3_hdr.o libmpdemux/mp_taglists.o libmpdemux/mpeg_hdr.o libmpdemux/mpeg_packetizer.o libmpdemux/parse_es.o libmpdemux/parse_mp4.o libmpdemux/video.o libmpdemux/yuv4mpeg.o libmpdemux/yuv4mpeg_ratio.o libvo/aclib.o libvo/osd.o libvo/sub.o osdep/getch2.o osdep/timer-darwin.o stream/open.o stream/stream.o stream/stream_cue.o stream/stream_file.o stream/stream_mf.o stream/stream_null.o stream/url.o libvo/font_load.o stream/stream_dvd.o stream/stream_dvd_common.o libdvdread/cmd_print.o libdvdread/dvd_input.o libdvdread/dvd_reader.o libdvdread/dvd_udf.o libdvdread/ifo_print.o libdvdread/ifo_read.o libdvdread/md5.o libdvdread/nav_print.o libdvdread/nav_read.o libmpcodecs/ad_faad.o libfaad2/bits.o libfaad2/cfft.o libfaad2/common.o libfaad2/decoder.o libfaad2/drc.o libfaad2/drm_dec.o libfaad2/error.o libfaad2/filtbank.o libfaad2/hcr.o libfaad2/huffman.o libfaad2/ic_predict.o libfaad2/is.o libfaad2/lt_predict.o libfaad2/mdct.o libfaad2/mp4.o libfaad2/ms.o libfaad2/output.o libfaad2/pns.o libfaad2/ps_dec.o libfaad2/ps_syntax.o libfaad2/pulse.o libfaad2/rvlc.o libfaad2/sbr_dct.o libfaad2/sbr_dec.o libfaad2/sbr_e_nf.o libfaad2/sbr_fbt.o libfaad2/sbr_hfadj.o libfaad2/sbr_hfgen.o libfaad2/sbr_huff.o libfaad2/sbr_qmf.o libfaad2/sbr_syntax.o libfaad2/sbr_tf_grid.o libfaad2/specrec.o libfaad2/ssr.o libfaad2/ssr_fb.o libfaad2/ssr_ipqf.o libfaad2/syntax.o libfaad2/tns.o stream/stream_ftp.o libmpcodecs/vf_bmovl.o libaf/af_export.o osdep/mmap_anon.o av_opts.o libaf/af_lavcresample.o libmpcodecs/ad_ffmpeg.o libmpcodecs/vd_ffmpeg.o libmpcodecs/vf_lavc.o libmpcodecs/vf_lavcdeint.o libmpcodecs/vf_screenshot.o libaf/af_lavcac3enc.o libmpcodecs/vf_fspp.o libmpcodecs/vf_geq.o libmpcodecs/vf_mcdeint.o libmpcodecs/vf_qp.o libmpcodecs/vf_spp.o libmpcodecs/vf_uspp.o libmpdemux/demux_lavf.o libdvdcss/css.o libdvdcss/device.o libdvdcss/error.o libdvdcss/ioctl.o libdvdcss/libdvdcss.o libmpcodecs/vd_libmpeg2.o libmpeg2/alloc.o libmpeg2/cpu_accel.o libmpeg2/cpu_state.o libmpeg2/decode.o libmpeg2/header.o libmpeg2/idct.o libmpeg2/motion_comp.o libmpeg2/slice.o libmpcodecs/vf_pp.o libmpcodecs/ad_libvorbis.o libmpdemux/demux_ogg.o libmpcodecs/ad_mp3lib.o mp3lib/sr1.o stream/stream_rtsp.o stream/freesdp/common.o stream/freesdp/errorlist.o stream/freesdp/parser.o stream/librtsp/rtsp.o stream/librtsp/rtsp_rtp.o stream/librtsp/rtsp_session.o osdep/shmem.o stream/stream_netstream.o stream/asf_mmst_streaming.o stream/asf_streaming.o stream/cookies.o stream/http.o stream/network.o stream/pnm.o stream/rtp.o stream/udp.o stream/tcp.o stream/stream_rtp.o stream/stream_udp.o stream/realrtsp/asmrp.o stream/realrtsp/real.o stream/realrtsp/rmff.o stream/realrtsp/sdpplin.o stream/realrtsp/xbuffer.o libmpcodecs/ad_qtaudio.o libmpcodecs/vd_qtvideo.o libmpcodecs/ad_realaud.o libmpcodecs/vd_realvid.o stream/cache2.o tremor/bitwise.o tremor/block.o tremor/codebook.o tremor/floor0.o tremor/floor1.o tremor/framing.o tremor/info.o tremor/mapping0.o tremor/mdct.o tremor/registry.o tremor/res012.o tremor/sharedbook.o tremor/synthesis.o tremor/window.o stream/stream_tv.o stream/tv.o stream/frequencies.o stream/tvi_dummy.o unrar_exec.o stream/stream_vcd.o libmpcodecs/vd_xanim.o libavformat/libavformat.a libavcodec/libavcodec.a libavutil/libavutil.a libpostproc/libpostproc.a libswscale/libswscale.a -framework OpenAL -L/usr/local/lib -liconv -lncurses -framework CoreAudio -framework AudioUnit -framework AudioToolbox -framework Cocoa -framework QuartzCore -framework OpenGL -framework IOKit -framework IOKit -lz -lm Undefined symbols: "_LoadLibraryA", referenced from: _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _init in vd_qtvideo.o _init in vd_qtvideo.o "_SetSystemUIMode", referenced from: _uninit in vo_macosx.o -[MPlayerOpenGLView fullscreen:] in vo_macosx.o -[MPlayerOpenGLView fullscreen:] in vo_macosx.o "_GetProcAddress", referenced from: _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _preinit in ad_qtaudio.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o _init in vd_qtvideo.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [mplayer] Error 1 This looks odd because there's a lot of identical lines... Do you have any idea of how to fix this? Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
"_LoadLibraryA", referenced from: "_GetProcAddress", referenced from:
QuickTime is not available in 64 bit. You have to use QTKit which doesn't quite do the same things. I doubt QuickTime will ever be ported to 64 bit so it's probably best to disable QT based code if building for x86_64 or ppc64 on a Mac.
"_SetSystemUIMode", referenced from:
http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/... /apple_ref/doc/uid/TP40004381-CH3-SW14 Specifically the line: Carbon Human Interface Toolbox. APIs such as the Window Manager, Menu Manager, Data Browser, HIView, HIToolbar, and HIArchive are not available to 64-bit applications. You must implement your user interface with Cocoa. See “Choosing a Development Path for Your Carbon User Interface.” SetSystemUIMode is in HIToolbox so isn't available to 64 bit apps. Besides that Apple gives strong warnings NOT to use it. You should be using CoreGraphics instead. I don't know if the QT BeginFullScreen call is available through QTKit or not, that was another easy way to do it. -DrD-
Hello, On Wed, Oct 29, 2008 at 12:46 AM, David DeHaven <dave@sagetv.com> wrote:
"_LoadLibraryA", referenced from: "_GetProcAddress", referenced from:
QuickTime is not available in 64 bit. You have to use QTKit which doesn't quite do the same things. I doubt QuickTime will ever be ported to 64 bit so it's probably best to disable QT based code if building for x86_64 or ppc64 on a Mac.
Ok. They do go away when I pass --disable-qtx to MPlayer's configue. Configure script should check if it can be compiled/linked IMHO. Here's what link stage looks like now: Undefined symbols: "_SetSystemUIMode", referenced from: _uninit in vo_macosx.o -[MPlayerOpenGLView fullscreen:] in vo_macosx.o -[MPlayerOpenGLView fullscreen:] in vo_macosx.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [mplayer] Error 1
"_SetSystemUIMode", referenced from:
http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/... /apple_ref/doc/uid/TP40004381-CH3-SW14
Specifically the line: Carbon Human Interface Toolbox. APIs such as the Window Manager, Menu Manager, Data Browser, HIView, HIToolbar, and HIArchive are not available to 64-bit applications. You must implement your user interface with Cocoa. See "Choosing a Development Path for Your Carbon User Interface."
SetSystemUIMode is in HIToolbox so isn't available to 64 bit apps.
Besides that Apple gives strong warnings NOT to use it. You should be using CoreGraphics instead. I don't know if the QT BeginFullScreen call is available through QTKit or not, that was another easy way to do it.
Ok, thanks for the explanation. I think that this patch should be reviewed now and considered for inclusion. Fullscreen support in 64 bits mode can be dealt with later. Nicolas, Ulion, what do you think about the patch? Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
On Oct 29, 2008, at 5:33 AM, Guillaume POIRIER wrote:
SetSystemUIMode is in HIToolbox so isn't available to 64 bit apps.
Besides that Apple gives strong warnings NOT to use it. You should be using CoreGraphics instead. I don't know if the QT BeginFullScreen call is available through QTKit or not, that was another easy way to do it.
Ok, thanks for the explanation. I think that this patch should be reviewed now and considered for inclusion. Fullscreen support in 64 bits mode can be dealt with later.
Nicolas, Ulion, what do you think about the patch?
I'm too busy at the moment to really help, but using CG to gain fullscreen mode is fairly trivial: http://developer.apple.com/documentation/GraphicsImaging/Conceptual/QuartzDi... I've done this several times and there's really nothing to it if all you want to do is capture the main display. -DrD-
I'm too busy at the moment to really help, but using CG to gain fullscreen mode is fairly trivial: http://developer.apple.com/documentation/GraphicsImaging/Conceptual/QuartzDi...
I've done this several times and there's really nothing to it if all you want to do is capture the main display.
unfortunately, it's not that simple. CGDisplayCapture could be used allright - but then you'll end up with a black screen because the opengl view that displays the frames is contained in a window and that window will stop rendering when the display is captured. for corevideo/opengl rendering to work in fullscreen mode, there are two options: - capture the display and create a fullscreen opengl rendering context - scale the output window to fullscreen size and disable titlebar and dock (this is what vo_macosx currently does, but with a carbon function) luckily, in this particular case, apple makes it easy: the code can be kept as it is. a small part of the carbon functions has been left in place, and SetSystemUIMode is one of them: http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/... so i put the -framework Carbon back for vo_macosx. i got ssh access to a 64bit mac running 10.5, and it builds. testing wasn't possible though, obviously. the next task would be fixing liba52: cc -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after- statement -std=gnu99 -mmacosx-version-min=10.5 -isysroot /Developer/ SDKs/MacOSX10.5.sdk -arch x86_64 -mdynamic-no-pic -falign-loops=16 - shared-libgcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 - D_LARGEFILE64_SOURCE -I. -I/usr/local/include -I/usr/X11/include -I/ usr/X11/include/freetype2 -I/usr/X11/include -c -o liba52/resample.o liba52/resample.c /var/tmp//ccwLM6D8.s:1177:32-bit absolute addressing is not supported for x86-64 /usr/libexec/gcc/i686-apple-darwin9/4.0.1/as: fatal error in /usr/ bin/../libexec/gcc/darwin/x86_64/as here's the updated patch. i also removed QuitApplicationEventLoop from osdep/macosx_finder_args.c, as it's gone for 64bit and the docs say it's normally not neccessary. for some reason, there's a regression here, though: the quit menu item doesn't work (other menu entries and cmd-q do), but it doesn't work with QuitApplicationEventLoop either, so that looks unrelated.
Hello, On Wed, Oct 29, 2008 at 7:26 PM, Gregor Riepl <onitake@gmail.com> wrote:
I'm too busy at the moment to really help, but using CG to gain fullscreen mode is fairly trivial:
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/QuartzDi...
I've done this several times and there's really nothing to it if all you want to do is capture the main display.
unfortunately, it's not that simple. CGDisplayCapture could be used allright - but then you'll end up with a black screen because the opengl view that displays the frames is contained in a window and that window will stop rendering when the display is captured. for corevideo/opengl rendering to work in fullscreen mode, there are two options: - capture the display and create a fullscreen opengl rendering context - scale the output window to fullscreen size and disable titlebar and dock (this is what vo_macosx currently does, but with a carbon function)
luckily, in this particular case, apple makes it easy: the code can be kept as it is. a small part of the carbon functions has been left in place, and SetSystemUIMode is one of them: http://developer.apple.com/documentation/Carbon/Conceptual/Carbon64BitGuide/... so i put the -framework Carbon back for vo_macosx.
i got ssh access to a 64bit mac running 10.5, and it builds. testing wasn't possible though, obviously.
Tested on may MacBookPro running OSX 10.5.5, and it works wonderfully if I run configure as follows: CC="gcc -arch x86_64" ./configure --disable-liba52-internal --disable-qtx
the next task would be fixing liba52: cc -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch x86_64 -mdynamic-no-pic -falign-loops=16 -shared-libgcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/local/include -I/usr/X11/include -I/usr/X11/include/freetype2 -I/usr/X11/include -c -o liba52/resample.o liba52/resample.c /var/tmp//ccwLM6D8.s:1177:32-bit absolute addressing is not supported for x86-64 /usr/libexec/gcc/i686-apple-darwin9/4.0.1/as: fatal error in /usr/bin/../libexec/gcc/darwin/x86_64/as
I ran into the same problem, but I honestly don't know what causes this problem. The same code builds fine on Linux/x86_64... When I look at the assembly code, it looks quite fine. Maybe it's a bug in Apple's fork of GAS?
here's the updated patch. i also removed QuitApplicationEventLoop from osdep/macosx_finder_args.c, as it's gone for 64bit and the docs say it's normally not neccessary. for some reason, there's a regression here, though: the quit menu item doesn't work (other menu entries and cmd-q do), but it doesn't work with QuitApplicationEventLoop either, so that looks unrelated.
works fine, outstanding work. Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
Tested on may MacBookPro running OSX 10.5.5, and it works wonderfully if I run configure as follows: CC="gcc -arch x86_64" ./configure --disable-liba52-internal -- disable-qtx
glad to hear that!
/var/tmp//ccwLM6D8.s:1177:32-bit absolute addressing is not supported for x86-64
I ran into the same problem, but I honestly don't know what causes this problem. The same code builds fine on Linux/x86_64... When I look at the assembly code, it looks quite fine. Maybe it's a bug in Apple's fork of GAS?
actually, it's a problem with apple's abi. in 64bit mode, only pic referencing and relative addressing is supported. since the constants are source-local and not used anywhere else, they could easily be referenced %rip-relative. are number literals a possibility? i remember vagely that movq to/from mmx registers is only possible from/to memory or other registers. according to this thread, the assembler is smart enough to generate relative addresses if (%rip) is specified after the symbol: http://lists.apple.com/archives/xcode-users/2006/Sep/msg00056.html here's a pointer to apple's docs on the topic: http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopi... the (%rip) approach works for resample_mmx.c, but not for imdct.c, as it already uses index addressing in a few places, and %rip can't be used as base register. the only way i see here would be something like lea _<constant>+<offset>(%rip), %rbp movq (%rbp,%r<index>), %mmx<x> i'm sure there are better options. no need to make the code more complex (and a slight bit slower) for architectures without this quirk.
Hello, On Wed, Oct 29, 2008 at 7:26 PM, Gregor Riepl <onitake@gmail.com> wrote: [..]
here's the updated patch. i also removed QuitApplicationEventLoop from osdep/macosx_finder_args.c, as it's gone for 64bit and the docs say it's normally not neccessary. for some reason, there's a regression here, though: the quit menu item doesn't work (other menu entries and cmd-q do), but it doesn't work with QuitApplicationEventLoop either, so that looks unrelated.
Diego, could you have a look at the patch to review the configure part of that patch? It would slim down the size of the patch a bit before it can hit SVN... I need to add a configure test for QTX too... Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
On Wed, Oct 29, 2008 at 07:26:58PM +0100, Gregor Riepl wrote:
here's the updated patch.
Here is a preliminary review...
--- configure (revision 27848) +++ configure (working copy) @@ -3521,14 +3521,28 @@ else _macosx=no _noaomodules="macosx $_noaomodules" - _novomodules="quartz $_novomodules" + _novomodules="macosx quartz $_novomodules"
That is a separate bug fix, committed.
if test "$_macosx" = yes ; then cat > $TMPC <<EOF +#include <CoreAudio/CoreAudio.h> +int main(void) { return 0; } +EOF
Just the presence of the header is enough? Don't you need to call a function or something?
+ if cc_check -framework CoreAudio; then + _ld_extra="$_ld_extra -framework CoreAudio -framework AudioUnit -framework AudioToolbox" + _coreaudio=yes + _def_coreaudio='#define CONFIG_COREAUDIO 1' + _aosrc="$_aosrc ao_macosx.c" + _aomodules="macosx $_aomodules" + else + _coreaudio=no + _def_coreaudio='#undef CONFIG_COREAUDIO' + _noaomodules="macosx $_noaomodules" + fi + cat > $TMPC <<EOF #include <Carbon/Carbon.h> #include <QuickTime/QuickTime.h> -#include <CoreAudio/CoreAudio.h> int main(void) {
It would be good if this ao_macosx check could be a separate patch.
@@ -3536,34 +3550,31 @@ -cat > $TMPC <<EOF -#include <Carbon/Carbon.h> + cat > $TMPC <<EOF +#include <Cocoa/Cocoa.h> #include <QuartzCore/CoreVideo.h> +#include <OpenGL/OpenGL.h> int main(void) { return 0; } EOF - if cc_check -framework Carbon -framework QuartzCore -framework OpenGL; then + _tmp_CFLAGS="$CFLAGS" + CFLAGS="$CFLAGS -x objective-c"
Does the check fail without this? And why do you use a temporary variable..
+ if cc_check -framework Cocoa -framework QuartzCore -framework OpenGL -framework Carbon; then
..when you can just add the flag to the compiler call here?
--- osdep/macosx_finder_args.c (revision 27848) +++ osdep/macosx_finder_args.c (working copy) @@ -85,7 +85,7 @@
- QuitApplicationEventLoop(); + //QuitApplicationEventLoop();
Separate patch? Also, you should add a comment that explains why this line is commented out or directly remove it. Diego
Hello, On Thu, Nov 13, 2008 at 1:18 AM, Diego Biurrun <diego@biurrun.de> wrote:
On Wed, Oct 29, 2008 at 07:26:58PM +0100, Gregor Riepl wrote:
here's the updated patch.
Here is a preliminary review...
--- configure (revision 27848) +++ configure (working copy) @@ -3521,14 +3521,28 @@ else _macosx=no _noaomodules="macosx $_noaomodules" - _novomodules="quartz $_novomodules" + _novomodules="macosx quartz $_novomodules"
That is a separate bug fix, committed.
if test "$_macosx" = yes ; then cat > $TMPC <<EOF +#include <CoreAudio/CoreAudio.h> +int main(void) { return 0; } +EOF
Just the presence of the header is enough? Don't you need to call a function or something?
Well, for the moment, yes, since the goal of this hunk is just to detect that CoreAudio is supported by the underlying OS, and it has been so since OSX 10.0. SVN version of the configure tests both Quartz and CoreAudio support, when Quartz in restricted to 32-bits, and CoreAudio both 32- and 64-bits compatible.
+ if cc_check -framework CoreAudio; then + _ld_extra="$_ld_extra -framework CoreAudio -framework AudioUnit -framework AudioToolbox" + _coreaudio=yes + _def_coreaudio='#define CONFIG_COREAUDIO 1' + _aosrc="$_aosrc ao_macosx.c" + _aomodules="macosx $_aomodules" + else + _coreaudio=no + _def_coreaudio='#undef CONFIG_COREAUDIO' + _noaomodules="macosx $_noaomodules" + fi + cat > $TMPC <<EOF #include <Carbon/Carbon.h> #include <QuickTime/QuickTime.h> -#include <CoreAudio/CoreAudio.h> int main(void) {
It would be good if this ao_macosx check could be a separate patch.
Ok, but other then that, it's OK? I can commit hunks seperately.
@@ -3536,34 +3550,31 @@ -cat > $TMPC <<EOF -#include <Carbon/Carbon.h> + cat > $TMPC <<EOF +#include <Cocoa/Cocoa.h> #include <QuartzCore/CoreVideo.h> +#include <OpenGL/OpenGL.h> int main(void) { return 0; } EOF - if cc_check -framework Carbon -framework QuartzCore -framework OpenGL; then + _tmp_CFLAGS="$CFLAGS" + CFLAGS="$CFLAGS -x objective-c"
Does the check fail without this?
Without what? I'm sorry but I'm not sure I get what you refer to by "this".
And why do you use a temporary variable..
+ if cc_check -framework Cocoa -framework QuartzCore -framework OpenGL -framework Carbon; then
..when you can just add the flag to the compiler call here?
Right, that's easy to fix...
--- osdep/macosx_finder_args.c (revision 27848) +++ osdep/macosx_finder_args.c (working copy) @@ -85,7 +85,7 @@
- QuitApplicationEventLoop(); + //QuitApplicationEventLoop();
Separate patch? Also, you should add a comment that explains why this line is commented out or directly remove it.
Here is what Gregor wrote about this: "I also removed QuitApplicationEventLoop from osdep/macosx_finder_args.c, as it's gone for 64bit and the docs say it's normally not necessary. for some reason, there's a regression here, though: the quit menu item doesn't work (other menu entries and cmd-q do), but it doesn't work with QuitApplicationEventLoop either, so that looks unrelated." I guess it should go in a separate patch. Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
Hello, On Tue, Nov 18, 2008 at 11:01 AM, Guillaume POIRIER <poirierg@gmail.com> wrote:
@@ -3536,34 +3550,31 @@ -cat > $TMPC <<EOF -#include <Carbon/Carbon.h> + cat > $TMPC <<EOF +#include <Cocoa/Cocoa.h> #include <QuartzCore/CoreVideo.h> +#include <OpenGL/OpenGL.h> int main(void) { return 0; } EOF - if cc_check -framework Carbon -framework QuartzCore -framework OpenGL; then + _tmp_CFLAGS="$CFLAGS" + CFLAGS="$CFLAGS -x objective-c"
Does the check fail without this?
Without what? I'm sorry but I'm not sure I get what you refer to by "this".
And why do you use a temporary variable..
+ if cc_check -framework Cocoa -framework QuartzCore -framework OpenGL -framework Carbon; then
..when you can just add the flag to the compiler call here?
Right, that's easy to fix...
I tested to pass -x objective-c to cc_check and it doesn't work. That's probably because -x option is sensitive to its place on the command line. As you probably saw, the temporary is to modify the CFLAGS temporarily before running the cc_check, then restoring the CFLAGS to their original. Anyay, the attached patch removes some more cosmetics from Gregor's original patch. Since I haven't heard a thing from any OSX devels from MPlayer dev team, I shall start pushing these changes to MPlayer dev tree soonish. Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
Hello, On Wed, Nov 19, 2008 at 12:35 AM, Guillaume POIRIER <poirierg@gmail.com> wrote:
Since I haven't heard a thing from any OSX devels from MPlayer dev team, I shall start pushing these changes to MPlayer dev tree soonish.
Here is the first part of the changes: replace QuickDraw calls in vo_quartz.c to fix warnings when compiling with current SDK versions. This will hit SVN this week-end unless I hear some objections. Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
Hello, On Wed, Nov 19, 2008 at 4:21 PM, Guillaume POIRIER <poirierg@gmail.com> wrote:
Hello,
On Wed, Nov 19, 2008 at 12:35 AM, Guillaume POIRIER <poirierg@gmail.com> wrote:
Since I haven't heard a thing from any OSX devels from MPlayer dev team, I shall start pushing these changes to MPlayer dev tree soonish.
Here is the first part of the changes: replace QuickDraw calls in vo_quartz.c to fix warnings when compiling with current SDK versions.
This will hit SVN this week-end unless I hear some objections.
Guillaume
Patch applied. Guillaume -- One should not give up hope on imbeciles. With a little training, you can make them into soldiers. -- Pierre Desproges
sorry, didn't have time to comment on your last mail. so i'm replying to this.
I tested to pass -x objective-c to cc_check and it doesn't work. That's probably because -x option is sensitive to its place on the command line. As you probably saw, the temporary is to modify the CFLAGS temporarily before running the cc_check, then restoring the CFLAGS to their original.
yes, this is exactly the case. the -x argument applies to all source files that follow, so it's vital to be placed in front of the conftest.c. i tried experimenting with a new objc_check(), but since gcc is used for both c and obj-c, it seemed overkill to me. would it be possible to modify compile_check() so that it moves its compiler arguments in front of the source file? or does that break everything?
Anyay, the attached patch removes some more cosmetics from Gregor's original patch.
Since I haven't heard a thing from any OSX devels from MPlayer dev team, I shall start pushing these changes to MPlayer dev tree soonish.
thank you :) by the way, my old macbook died last weekend, so i had to buy a new one. i can do 64bit compilation and testing directly now. by the way, i didn't manage to crosscompile mplayer for x86_64-darwin before. despite forcing --target and --enable-crosscompile, the configure script would still try to execute its cpu test program, complain and not create the correct config.h/config.mak.
Hello, Gregor Riepl wrote:
sorry, didn't have time to comment on your last mail. so i'm replying to this.
I tested to pass -x objective-c to cc_check and it doesn't work. That's probably because -x option is sensitive to its place on the command line. As you probably saw, the temporary is to modify the CFLAGS temporarily before running the cc_check, then restoring the CFLAGS to their original.
yes, this is exactly the case. the -x argument applies to all source files that follow, so it's vital to be placed in front of the conftest.c. i tried experimenting with a new objc_check(), but since gcc is used for both c and obj-c, it seemed overkill to me. would it be possible to modify compile_check() so that it moves its compiler arguments in front of the source file? or does that break everything?
I let Diego answer this question.
Anyay, the attached patch removes some more cosmetics from Gregor's original patch.
Since I haven't heard a thing from any OSX devels from MPlayer dev team, I shall start pushing these changes to MPlayer dev tree soonish.
thank you :)
by the way, my old macbook died last weekend,
That's sad news. Please receive all my sympathy: the screen of my MacBookPro got broken last summer, and my G5 is at the repair shop. This has been a bad year for me savings-wise.
so i had to buy a new one. i can do 64bit compilation and testing directly now.
Awesome.
by the way, i didn't manage to crosscompile mplayer for x86_64-darwin before. despite forcing --target and --enable-crosscompile, the configure script would still try to execute its cpu test program, complain and not create the correct config.h/config.mak.
It works here with the following commandline: CC="gcc -arch x86_64" ./configure --target=x86_64-darwin --disable-liba52-internal --disable-qtx Guillaume
On Wed, Nov 19, 2008 at 04:26:29PM +0100, Gregor Riepl wrote:
I tested to pass -x objective-c to cc_check and it doesn't work. That's probably because -x option is sensitive to its place on the command line. As you probably saw, the temporary is to modify the CFLAGS temporarily before running the cc_check, then restoring the CFLAGS to their original.
yes, this is exactly the case. the -x argument applies to all source files that follow, so it's vital to be placed in front of the conftest.c. i tried experimenting with a new objc_check(), but since gcc is used for both c and obj-c, it seemed overkill to me. would it be possible to modify compile_check() so that it moves its compiler arguments in front of the source file? or does that break everything?
I don't think so and in fact I think it already does: $_cc $CFLAGS $_inc_extra $_ld_static $_ld_extra $_libs_mplayer $_libs_mencoder -o "$TMPEXE" "$@" >> "$TMPLOG" 2>&1 Am I missing something here? Diego
On Tue, Nov 18, 2008 at 11:01:15AM +0100, Guillaume POIRIER wrote:
On Thu, Nov 13, 2008 at 1:18 AM, Diego Biurrun <diego@biurrun.de> wrote:
On Wed, Oct 29, 2008 at 07:26:58PM +0100, Gregor Riepl wrote:
here's the updated patch.
Here is a preliminary review...
+ if cc_check -framework CoreAudio; then + _ld_extra="$_ld_extra -framework CoreAudio -framework AudioUnit -framework AudioToolbox" + _coreaudio=yes + _def_coreaudio='#define CONFIG_COREAUDIO 1' + _aosrc="$_aosrc ao_macosx.c" + _aomodules="macosx $_aomodules" + else + _coreaudio=no + _def_coreaudio='#undef CONFIG_COREAUDIO' + _noaomodules="macosx $_noaomodules" + fi + cat > $TMPC <<EOF #include <Carbon/Carbon.h> #include <QuickTime/QuickTime.h> -#include <CoreAudio/CoreAudio.h> int main(void) {
It would be good if this ao_macosx check could be a separate patch.
Ok, but other then that, it's OK? I can commit hunks seperately.
Other than that the hunk is OK, commit it. Diego
Hello, 2008/10/29 Gregor Riepl <onitake@gmail.com>:
here's the updated patch. i also removed QuitApplicationEventLoop from osdep/macosx_finder_args.c, as it's gone for 64bit and the docs say it's normally not neccessary. for some reason, there's a regression here, though: the quit menu item doesn't work (other menu entries and cmd-q do), but it doesn't work with QuitApplicationEventLoop either, so that looks unrelated.
For the record, here's what Apple's doc has to say about this function: QuitApplicationEventLoop Terminates the application event loop. void QuitApplicationEventLoop ( void ); Discussion This function is used to quit the RunApplicationEventLoop<file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Carbon/Reference/Carbon_Event_Manager_Ref/Reference/reference.html#//apple_ref/c/func/RunApplicationEventLoop> function. Typically, your application doesn't need to call this. If your application has the Quit menu item tagged with the kHICommandQuit menu command ID, the toolbox will automatically call this for your application, automatically terminating your event loop. If your application wants to do pre-processing before the event loop exits, it should intercept either the kHICommandQuit menu command, or the kEventAppQuit event. Availability - Available in Mac OS X v10.0 and later. - Not available to 64-bit applications. Declared InCarbonEvents.h I don't see further reason to not remove that call now. Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Stephen Leacock - "I detest life-insurance agents: they always argue that I shall some day die, which is not so."
Typically, your application doesn't need to call this. If your application has the Quit menu item tagged with the kHICommandQuit menu command ID, the toolbox will automatically call this for your application, automatically terminating your event loop. If your application wants to do pre- processing before the event loop exits, it should intercept either the kHICommandQuit menu command, or the kEventAppQuit event.
I don't see further reason to not remove that call now.
yes, i saw that part too. that's why i didn't bother finding a replacement. and quitting (via cmd-q or q) worked just fine without QuitApplicationEventLoop. by the way, i checked the assembly incompatibilites. looks like a lot of work. in some places, simply modifying the MANGLE macro would work (adding a (%%rip) to it), but in others, this will fail. using __asm__ constraints is another possibility, but will also not work everywhere. gcc showed some inconsistent behaviour, which would have to be worked around. the best way might be writing special 64bit versions of the routines, and they could also take advantage of the additional registers. but i doubt people will approve to this, as it's a lot of work, complicates code and provides little performance gain. i did a quick speed test with 32bit and 64bit compilation (with added registers) of vf_fspp.c, but noticed no significant difference. this doesn't mean it's a good idea to get rid of deprecated calls, but it makes a 64bit os x port more questionable. to me at least.
Hello, On Mon, Dec 15, 2008 at 1:37 PM, Gregor Riepl <onitake@gmail.com> wrote:
Typically, your application doesn't need to call this. If your application has the Quit menu item tagged with the kHICommandQuit menu command ID, the toolbox will automatically call this for your application, automatically terminating your event loop. If your application wants to do pre- processing before the event loop exits, it should intercept either the kHICommandQuit menu command, or the kEventAppQuit event.
I don't see further reason to not remove that call now.
yes, i saw that part too. that's why i didn't bother finding a replacement. and quitting (via cmd-q or q) worked just fine without QuitApplicationEventLoop.
Confirmed. I wonder if that call is there only so that MPlayerOSX works fine... We'll see how things go once this change gets merged.
by the way, i checked the assembly incompatibilites. looks like a lot of work. in some places, simply modifying the MANGLE macro would work (adding a (%%rip) to it), but in others, this will fail. using __asm__ constraints is another possibility, but will also not work everywhere. gcc showed some inconsistent behaviour, which would have to be worked around. the best way might be writing special 64bit versions of the routines, and they could also take advantage of the additional registers. but i doubt people will approve to this, as it's a lot of work, complicates code and provides little performance gain. i did a quick speed test with 32bit and 64bit compilation (with added registers) of vf_fspp.c, but noticed no significant difference.
vf_fspp.c doesn't need modified ASM. It can compile fine if you change optimization level from -O4 to -O2. 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...
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?
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. Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Robert Orben - "Older people shouldn't eat health food, they need all the preservatives they can get."
On Mon, Dec 15, 2008 at 02:00:54PM +0100, Guillaume POIRIER wrote:
in some places, simply modifying the MANGLE macro would work (adding a (%%rip) to it)
Why is this necessary? Does OSX 64 bit not support relocations _at all_?
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...
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).
Hello, On Mon, Dec 15, 2008 at 2:39 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Mon, Dec 15, 2008 at 02:00:54PM +0100, Guillaume POIRIER wrote:
in some places, simply modifying the MANGLE macro would work (adding a (%%rip) to it)
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/MachOTopi...
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...
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? What is FFmpeg's AC3 good for there days? Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Stephen Leacock - "I detest life-insurance agents: they always argue that I shall some day die, which is not so."
On Mon, Dec 15, 2008 at 03:04:03PM +0100, Guillaume POIRIER wrote:
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...
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.
What is FFmpeg's AC3 good for there days?
AC3 in MKV, probably also works with -demuxer lavf (forgot about that).
Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs.
Too bad that they only now figure out that ifdefs can do quite a lot too, and that commented-out code can be activated again, particularly when you have an interpreter with such crazy semantics ;-)
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/MachOTopi... /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?
On Mon, Dec 15, 2008 at 04:59:24PM +0100, Gregor Riepl wrote:
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.
Mostly H.264, but 10 % should be realistic there.
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/MachOTopi... /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?
Huh? That sounds like the completely normal process for 64 bit systems, but that normally only applies to PIC/PIE code (rip-relative addressing is just an attempt to make PIC not be uselessly slow in the worst-case).
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)
I don't like it much because my compilation attempts on OpenBSD and FreeBSD have made me painfully aware that gcc will mess it up most of the time - using "m" constraints is simply a sure way to get the "could not find a register in GENERAL_REGS" error in at least one gcc version (unless you have less than 5 arguments + register clobbers total). In addition I am not sure if the generated code properly uses PIC-relative addressing, if not it will be slower. Btw. libav* uses this code instead of what is on mangle.h:
// Use rip-relative addressing if compiling PIC code on x86-64. #if defined(ARCH_X86_64) && defined(PIC) # define LOCAL_MANGLE(a) #a "(%%rip)" #else # define LOCAL_MANGLE(a) #a #endif
#define MANGLE(a) EXTERN_PREFIX LOCAL_MANGLE(a)
As you can see it does not think there is any reason to do anything different unless you are building a library, if OSX indeed is different FFmpeg needs to be fixed as well. Greetings, Reimar Döffinger
Hello, On Mon, Dec 15, 2008 at 5:29 PM, Reimar Döffinger <Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Btw. libav* uses this code instead of what is on mangle.h:
// Use rip-relative addressing if compiling PIC code on x86-64. #if defined(ARCH_X86_64) && defined(PIC) # define LOCAL_MANGLE(a) #a "(%%rip)" #else # define LOCAL_MANGLE(a) #a #endif
#define MANGLE(a) EXTERN_PREFIX LOCAL_MANGLE(a)
As you can see it does not think there is any reason to do anything different unless you are building a library, if OSX indeed is different FFmpeg needs to be fixed as well.
You nailed it. I have a local patch that uses FFmpeg's mangle + some modification to allow compilation with 64-bits x86 OSX. This allows me to compile all MPlayer and FFmpeg, minus the local copy of liba52. I can post the patch if needed. Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Bob Hope - "I don't feel old. I don't feel anything till noon. That's when it's time for my nap."
Huh? That sounds like the completely normal process for 64 bit systems, but that normally only applies to PIC/PIE code (rip-relative addressing is just an attempt to make PIC not be uselessly slow in the worst- case).
is that so? i was having the impression that other os kernels support segment-absolute addressing too - or the assembler/linker is smart enough to automatically translate.
+ :"m"(one_null), "m"(null_one)
I don't like it much because my compilation attempts on OpenBSD and FreeBSD have made me painfully aware that gcc will mess it up most of the time - using "m" constraints is simply a sure way to get the "could not find a register in GENERAL_REGS" error in at least one gcc version (unless you have less than 5 arguments + register clobbers total). In addition I am not sure if the generated code properly uses PIC-relative addressing, if not it will be slower.
now this is funny. one_null and null_one are memory references already, at least if the compiler doesn't do any magic tricks on them. so why allocate another register before handing them over to the assembly code? maybe the g constraint works better in this case...
// Use rip-relative addressing if compiling PIC code on x86-64. #if defined(ARCH_X86_64) && defined(PIC) # define LOCAL_MANGLE(a) #a "(%%rip)" #else # define LOCAL_MANGLE(a) #a #endif
#define MANGLE(a) EXTERN_PREFIX LOCAL_MANGLE(a)
As you can see it does not think there is any reason to do anything different unless you are building a library, if OSX indeed is different FFmpeg needs to be fixed as well.
this is very good news. if the code is already there, i second using it, as this is precisely what's needed. only indexing doesn't work like this, and that's the reason why a52 won't compile. sweeping arrays using an index register is not possible like this. but it would work with a lea instruction and another register, i guess.
On Mon, Dec 15, 2008 at 06:24:05PM +0100, Gregor Riepl wrote:
Huh? That sounds like the completely normal process for 64 bit systems, but that normally only applies to PIC/PIE code (rip-relative addressing is just an attempt to make PIC not be uselessly slow in the worst- case).
is that so? i was having the impression that other os kernels support segment-absolute addressing too - or the assembler/linker is smart enough to automatically translate.
Well, as I said normal for PIC/PIE code. I was not aware that OSX forces that.
this is very good news. if the code is already there, i second using it, as this is precisely what's needed. only indexing doesn't work like this, and that's the reason why a52 won't compile. sweeping arrays using an index register is not possible like this. but it would work with a lea instruction and another register, i guess.
When you're writing x86_64 specific code anyway you can just use "m" constraints for that, I hope you don't intend on using more than 12 asm arguments...
On 14 Dec 2008, at 23:57 , Guillaume POIRIER wrote:
I don't see further reason to not remove that call now.
If you remove that call, macosx_finder_args.c will simply stop working: the QuitApplicationEventLoop() call in AppleEventHandlerProc is there to stop the RunApplicationEventLoop() in macos_finder_args(), allowing the function to return the file list that was provided by the finder to the application.
Hello, On Mon, Dec 15, 2008 at 9:59 PM, Dario Roccati <roccati@pobox.com> wrote:
On 14 Dec 2008, at 23:57 , Guillaume POIRIER wrote:
I don't see further reason to not remove that call now.
If you remove that call, macosx_finder_args.c will simply stop working:
the QuitApplicationEventLoop() call in AppleEventHandlerProc is there to stop the RunApplicationEventLoop() in macos_finder_args(), allowing the function to return the file list that was provided by the finder to the application.
I'm happy to see someone finally reacting to that change. The thing is: I don't think I ever used Mplayer's Finder args feature. It's not even documented how it's supposed to work, and what to expect from it!!! Could you give me a test case so that I can check the behavior before and after the patch? In any case, something will have to be made about that piece of code, since it is not 64-bits friendly as is. Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Jay London - "I was going to buy a book on hair loss, but the pages kept falling out."
On 15 Dec 2008, at 22:24 , Guillaume POIRIER wrote:
I'm happy to see someone finally reacting to that change. The thing is: I don't think I ever used Mplayer's Finder args feature. It's not even documented how it's supposed to work, and what to expect from it!!!
The finder args feature was added by me long ago, in a (now forgotten) quest of providing mplayer with a mac-like interface. The code provided in osdep/macos_finder_args.c allows the executable to be wrapped inside an application bundle and to receive the files to be played via the finder, enabling the use of the (more or less) bare mplayer as a default application for video files.
Could you give me a test case so that I can check the behavior before and after the patch?
You need to wrap the executable in an application bundle, with an Info.plist defining atleast one supported file type; then you will be able to open that file type with mplayer using the "Open With" context menu. If you remove QuitApplicationEventLoop() the mplayer icon (whatever you provided in the application bundle) will appear in the dock, but mplayer will start playing the file after selecting "Quit MPlayer" from the "MPlayer" menu. If you leave the code as-is, the playback will start (as expected) immediately. If you need it, I can directly send you the application bundle with everything but the mplayer executable.
In any case, something will have to be made about that piece of code, since it is not 64-bits friendly as is.
I will check what the options are, but I'm still using MacOS 10.4.x (with a powermac G5).
Hello, On Mon, Dec 15, 2008 at 11:14 PM, Chris Roccati <roccati@pobox.com> wrote:
On 15 Dec 2008, at 22:24 , Guillaume POIRIER wrote:
Could you give me a test case so that I can check the behavior before and after the patch?
You need to wrap the executable in an application bundle, with an Info.plist defining atleast one supported file type; then you will be able to open that file type with mplayer using the "Open With" context menu.
If you remove QuitApplicationEventLoop() the mplayer icon (whatever you provided in the application bundle) will appear in the dock, but mplayer will start playing the file after selecting "Quit MPlayer" from the "MPlayer" menu. If you leave the code as-is, the playback will start (as expected) immediately.
I see. That's indeed not the behavior the user would expect.
If you need it, I can directly send you the application bundle with everything but the mplayer executable.
Yep, please do so. I have exactly zero knowledge on that part of OSX programming. Could you direct me to some documentation about that?
In any case, something will have to be made about that piece of code, since it is not 64-bits friendly as is.
I will check what the options are, but I'm still using MacOS 10.4.x (with a powermac G5).
Ok, very good. My PPC machine is running Tiger too. My laptop uses Leopard though. Guillaume -- Only a very small fraction of our DNA does anything; the rest is all comments and ifdefs. Bob Hope - "I don't feel old. I don't feel anything till noon. That's when it's time for my nap."
On 15 Dec 2008, at 23:24 , Guillaume POIRIER wrote:
I see. That's indeed not the behavior the user would expect.
The fact is, that a "real" MacOS X application should sit inside the AppleEvent handling loop and perform its work there. The way MPlayer works makes this impossible. So, I decided to perform a single "run" thru the AppleEvent handler to collect the files provided as arguments by the Finder, build a playlist, and continue thru the normal MPlayer main(). This is somewhat ugly, but when I did submit the patch, it looked like it was the only way for the patch to be accepted.
Yep, please do so. I have exactly zero knowledge on that part of OSX programming. Could you direct me to some documentation about that?
The application bundle "anatomy" is described here: http://developer.apple.com/documentation/CoreFoundation/Conceptual/ CFBundles/Concepts/BundleAnatomy.html The apple events handling is described here: http://developer.apple.com/documentation/AppleScript/Conceptual/ AppleEvents/
The finder args feature was added by me long ago, in a (now forgotten) quest of providing mplayer with a mac-like interface. The code provided in osdep/macos_finder_args.c allows the executable to be wrapped inside an application bundle and to receive the files to be played via the finder, enabling the use of the (more or less) bare mplayer as a default application for video files.
this is what i supposed it was. but since mplayerosx and mplayosxx run the mplayer binary directly (even though it sits in an app bundle inside the gui app), this was never really an issue, i suppose. thanks for enlightening us what the piece of code really does. about the forgotten bit: i must say, i've been wanting to try my hands at integrating mplayerosx into mplayer for quite some time, but i couldn't get up the courage (and time) to do it. if anyone's interested (or has already tried), please raise your hands! while the two-apps approach works quite well, it would be much nicer to have something like gmplayer for osx. adrian, you seem to have taken over maintaining the gui part on your own, what's your opinion?
On Wed, Dec 17, 2008 at 3:36 PM, Gregor Riepl <onitake@gmail.com> wrote:
about the forgotten bit: i must say, i've been wanting to try my hands at integrating mplayerosx into mplayer for quite some time, but i couldn't get up the courage (and time) to do it. if anyone's interested (or has already tried), please raise your hands! while the two-apps approach works quite well, it would be much nicer to have something like gmplayer for osx.
adrian, you seem to have taken over maintaining the gui part on your own, what's your opinion?
A tighter integration would certainly benefit most GUIs, which currently have to work around the limitations of working with MPlayer as an application. But it seems to me it would need a lot of work to implement. The idea of an mplayer library has been brought up before and the point has been made that such a change would require fundamental changes to MPlayer. Currently, I think my time is better spent on MPlayer OSX where more improvements can be made with less effort. Though if someone would decide to work on this I would be certainly be willing to help. Greetings Adrian
But it seems to me it would need a lot of work to implement. The idea of an mplayer library has been brought up before and the point has been made that such a change would require fundamental changes to MPlayer.
i know. i've followed mplayer development almost since the beginning, though not as a developer. point is, i didn't want to go so far as making mplayer into a library. but there is gmplayer, so it must be possible to make gui'd versions for other platforms too. however difficult it may be.
Currently, I think my time is better spent on MPlayer OSX where more improvements can be made with less effort. Though if someone would decide to work on this I would be certainly be willing to help.
fair enough. someone's got to get the stone rolling. i'd have preferred if lots of people joined in, but i can understand that everyone has their own priorities.
On 3-Oct-08, at 11:49 AM, Gregor Riepl wrote:
Sorry for the confusion.
your first statement was perfectly intelligible. :)
anyway, i dug up a two things. first, UpdateSystemActivity is nowhere mentioned as being deprecated or not available. it's even in the CoreServices/OSServices framework for all 4 supported architectures. the only problem is that apple inserted a #if !__LP64__ #ifndef __POWER__ #include <OSServices/Power.h> #endif into /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OSServices.h, which makes the compiler fail. the linker would in fact succeed. i filed a bug (radar #6267445) against this.
second, up from 10.5, there is a replacement for this function: IOPMAssertionCreate(kIOPMAssertionTypeNoDisplaySleep, kIOPMAssertionLevelOn, &assertionID); the problem is that this only disables display power management and not the screensaver. i have yet to find a good way to do this. people suggest defaults write com.apple.screensaver write idleTime 0 but this looks like a terrible hack to me and it seems setting it back to a positive number doesn't turn the screensaver back on again.
here's an updated patch. i don't suggest applying it yet, as it switches to IOPMAssertion when compiling for 10.5, and the screensaver is still on. but you can test if it works on x86_64, if you like.
i hope apple helps with a permanent solution.
<mplayer-svn27682-quartz-macosx-deprecated.patch>
I fixed the patch and removed cosmetic change. Is this patch still current? If yes, its ok to apply (some cleanup left to do I think)
participants (12)
-
Adrian Stutz -
Chris Roccati -
Dario Roccati
-
David DeHaven -
Diego Biurrun -
Gregor Riepl -
Guillaume POIRIER -
Guillaume Poirier -
Nicolas Plourde -
onitake
-
Reimar Döffinger -
Ulion