I'm new to Mac programming and am really getting confused on what is the correct way to capture any webcam.
Learnt:
On Windows - Directshow filters are the only recommended way.
On Mac, there are atleast three frameworks. This is what I've understood by searching through the forums. Please correct me if I am wrong.
QuickTime - 32 bit applications only
QTKit - 64 bit applications only
AV Foundation - OS X 10.7 and above.
(I've gone through some posts which said - when QTKit is used, some webcams were not even recognized. But did't understand what to do)
Requirement: Capture any Webcam (internal or external - any vendor) on Mac OS X 10.7 and above in a 64 bit application, which is built on OS X 10.6 (due to large chunk of frameworks not migrated to Xcode 4 at the current moment code has to be built on Xcode 3.2.5 on OS X 10.6. We are planning to migrate to Xcode 4, but it takes more time and cant fit it in the current release schedule). So, I cant use AV Foundation.
Question: If we use QTKit alone, will the application be able to capture all webcams? Or some webcams with 32 bit drivers or drivers which support only AV Foundation fail? Is the right way to capture on Mac is to implement the capture functionality using all three frameworks?
Related
Having my webcam plugged in, I'm able to manipulate the video/audio stream in my MAC OS app.
Now I'd like to output it as a new virtual video/audio device that I can select as a camera input in apps like "Skype" or QuickTime.
I've looked into i/o kit framework and the reference webpage says this:
"To add digital video capabilities to your software, use the QuickTime
APIs."
I believe this needs to be updated because QuickTime APIs have been replaced by CoreMedia IO.
So I looked into CoreMediaIO and found a sample code from Apple dev website that also is obsolete and won't run on XCode 7.x with OS Yosemite+.
I've also looked in AVFoundation but it seems like a dead end.
I'm lost at this point. I know it's doable since CamTwist software is doing it.
Anyone has an idea how to approach this?
CoreMediaIO is definitely the way to go, as that's what Apple currently uses in its hardware. On my system (2015 rMBP), /Library/CoreMediaIO/Plug-Ins/DAL/ contains AppleCamera.plugin and iOSScreenCapture.plugin, for the webcam and capturing from iDevice.
I assume the example you're referring to is this one?
It doesn't quite compile out of the box, but I got it to build with the OSX 10.11 SDK eventually. You need Apple's Core Audio Utility Classes, point the 'Sources/Extras/CoreAudio/PublicUtility' group in the Xcode project at those, and then fix a variable initialisation (remove the = NULL where it complains about a private constructor) and comment out a few lines in SamplePrefix.h. I haven't run it, but I see no reason why it wouldn't. If you don't have a kext signing certificate, you may need to take steps to load unsigned kexts to run the sample.
Is your webcam using the old video-digitaizer driver (driver .component file is located in /Library/QuickTime)? I was able to see my UVC-camera and DAL camera in QuickTime player. My understanding is that Apps written in AVFoundation will not recongize old vdig driver. On the contrary, Apps written using Sequence Grabber (very old) / QTCapture (old) will recongize your device.
Hope this helps.
I have developed a Cocoa App on Lion and now I would like to add compatibility with Leopard and Snow Leopard.
I tried to set the development target to 10.5 but it still has crash problems on Leopard and Snow Leopard.
I tried also to open the project with old versions of Xcode, but I get hundreds of compile errors (I guess it's because I can't compile the program with the old Mac OS SDK)
Do you have any advice about solving the retro-compatibility problems of Cocoa Apps?
I think it's generally not a very good idea to develop for the latest OS then try to support older OSes at the last minute. If you've used any APIs that were introduced in an OS later than the oldest you're trying to support, you'll have to rewrite code to avoid using those APIs. It's generally not worth the trouble.
That said, there's no secret to supporting older OSes. You just need to make sure that you only use APIs (classes, methods, functions) that are available on the oldest OS you're trying to support. You'll notice when looking at the documentation that for each method, under "Availability", it will tell you which versions of the OS include that method. Something like:
Availability
Available in Mac OS X v10.6 and later.
Assuming you don't use any APIs not available on an OS version you're targeting, all you need to do is set the deployment target to the lowest OS you're targeting, and build. You will of course also want to test thoroughly on each OS version you're supporting.
Your question would be easier to answer in more detail if you elaborated on the "crash problems" you're seeing on Leopard and Snow Leopard.
First, install the 10.5 SDK on your Mac. This may not be necessary, but do it anyway. You can find instructions on the Internet. Keep in mind that compiling with the 10.5 SDK will ensure compatibility, but you won't be able to use newer OS X features unless you load them dynamically.
Second, go into your .xib files and on the File Properties tab (first notch in the Inspector pane) disable auto layout and set the deployment target to 10.5.
I just upgraded to Flash Builder 4.5, and I am trying to decide whether to install the Win or OS X version, since Adobe only allows you to install on one platform. I have been, up until now, developing an AS3 application using FB 4 under Windows 7 on my MacBook, and my Production Premium CS5 license is also for Windows (and I also do C++/Visual Studio development as well). Now I am going to try the iPhone Packager, to port my app to iOS. It seems to me that the workflow will be awkward once I cross-compile to Objective-C - as I will need to either reboot into OS X to compile and debug, or I will need to run FB 4.5 in a parallels session under OS X (though Adobe's activation freaked out when I tried this with Prod Prem CS4). The FB 4.5 / iOS workflow still requires xCode does it not? Is it foolish to even try this? Should I just bite the bullet and switch over to working in OSX?
Thanks!
I'd say it's better to keep things simple and stick with OSX. Constant switching among platforms is a sure productivity killer. Bite the bullet and stay on OSX - it will pay off on the mid run.
You're better off doing all of this in OSX
I'm developing something for Mac OS X. It's a port of a Windows product.
One of my boss' concerns is how it will run on older versions of Mac OS X. I know Xcode has facilities for compiling for old versions of Mac OS X, but QA would prefer to actually run the older versions of Mac OS X on a Macintosh.
Since we got into Macintosh development after Snow Leopard was released, all of our machines come with Snow Leopard (10.6). As far as I know, you can't really walk into a store to buy Leopard (10.5) and anything prior to that is basically extinct.
In a question on virtualization someone said that they've done multi-boot or multiple hard drives for other versions of Mac OS X, but I'm not sure how one would obtain the install media or the license for an old version.
I see Apple has their Mac Developer Program which touts as one of its features as "access pre-release versions of the latest software" which is cool, but I don't see it anywhere on there that old versions of Mac OS X are available. Does Apple have an MSDN-equivalent where old versions of the software are available for download?
Also, is there a reliable breakdown somewhere of the rate of upgrades/updates to Mac OS X? (i.e., what % of users still run Mac OS X 10.5, 10.4, PPC-based machines, etc.)
In case you buy an old OS X from Amazon or other retailers, note that you can not install an OS which was released before the hardware was announced. Older OSes just don't have the required driver to be able to run on a newer machine, and Apple doesn't back-port drivers for older OSes. In other words, if you buy the latest new Mac from Apple, you can't install 10.5 or 10.4 or whatever. So, you need to buy an old Mac too, not just an old OS.
The breakdown of the OS ratio really depends on the software. For example, the veritable Omnigroup publishes this version breakdown of the hits of their software update server. There are many websites which tell you the version break down, see e.g. this site.
Judging from it, I would say Snow Leopard covers half of the Macs in the world. Supporting Leopard might be worth while if you have extra resources. But I would guess people who didn't buy Snow Leopard won't typically buy a new 3rd party app, so supporting Leopard won't give you 50% increase in the number of potential buyers. (I admit this last sentence is completely subjective, though.)
Apple Developer Connection does have most older OS version available for download, but it's not quite from a complete collection (specifically, they're missing a full install of 10.4.anything for Intel CPUs). They do have the GM builds of 10.6.0 (which is Intel only), 10.5.0 (Intel/PPC universal), 10.4.0 (PPC only), 10.3.0, and 10.2.0.
As others have said, you won't be able to use older versions of the OS on newer hardware, so you're going to have to get used computers for testing -- if purchasing doesn't like eBay &c, look for a company that specializes in used equipment, like PC Recycle. For maximum coverage, I'd recommend getting an Intel Mac that shipped with 10.4 (and make sure you get the installer disks that came with it), and a PPC Mac with that's as old as possible while still having a 867MHz+ G4 CPU (so you can run 10.5 on it, and don't have to worry about weird G5 builds) (again, be sure to get its original disks 'cause an older generic installer won't work).
One option (besides acquiring old OS versions yourself) is to use the compatibility labs that Apple maintains. Lots of machines, old and new, already set up with many different versions of the OS.
I believe you can get a "day pass" to the labs for ~$100. Depending on where exactly you're located and the cost of getting to Cupertino, this may or may not be a viable option for you.
http://developer.apple.com/labs/
As others noted, a number of sellers on Amazon have boxed old versions of the OS.
Historically, people used to boot off external Firewire drives to use older or beta OS versions, but of course some of the newer machines lack Firewire ports. I know EFI does support some external boot options (netboot for instance).
It might be possible to boot newer Intel hardware using a late version of 10.4 - but I couldn't guarantee it (as another poster noted, 10.4 won't have relevant hardware drivers - but there are basic generic drivers that may work. Then again, is that a realistic test???).
As an addition to Yuji's post - there are some people who are forced to stick with Leopard or Tiger for compatibility reasons (my father can't upgrade all the machines at his school, because the A3 colour printer only has generic printer support under Snow Leopard, and they also have a lot of older Adobe software). I would say that generally this applies more with institutional customers - for educational software running on 10.4, and even running on PowerPC hardware, can still be a significant issue.
For consumer software - less so - the big spike in Mac sales came after the switch to Intel, and almost all active consumer software purchasers are on Intel machines running 10.5 or later.
The other thing that needs to be considered is that 10.4 is missing many APIs introduced in 10.5 and 10.6.
Is it possible to develop an application for a Windows Mobile device, on Mac OS X?
This question mostly due to this answer, criticising Apple for only releasing the iPhone developer tools for the Mac platform..
I'm simply curious if this is possible or not, hopefully an Apple-vs-Microsoft argument can be avoided! There are similar questions for iPhone-development on Windows (1, 2, 3), but not the other way around!
MonoDevelop will run on Mac OS X and according to their FAQ it could be possible to create applications for the Compact Framework, but only after running a patcher (mentioned in the FAQ).
It does look like you wouldn't have any real debug support for the Compact Framework, as you can't install it on Mac OS X and the Windows Mobile emulators can't be used on OS X either.
You can always run Windows virtualized in VMWare, Parallels, VirtualBox or with BootCamp.