Well they could have written two version of it the one that uses the quick sync the other to use the encoding decoding abiltiy of the gpu which has been able to do this for a while but they have not
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Enabling AirPlay mirroring on an unsupported Mac
- Thread starter Lunaticx
- Start date
- Sort by reaction score
Who said x264 has to take compressed input? It can and does take uncompressed input. But nice try though.
Judging from your statements, it seems you are running handbrake with a compressed source input. Of course your cores are going to be loaded. You're doing decoding AND encoding.
----------
Consistent user experience? Most of the owners of Macs now cannot Airplay mirror. How's that for consistent?
As for positive user experience, I still submit it's technically and feasible possible to provide a smooth interaction with Airplay to machines that are quad-core Nehalem or better.
They could - but I doubt that they wanted to. They wanted something easy to support that they knew would work well - Quick Sync - rather than worry about other systems that would not work quite well or confusing people further for people who do not have dedicated GPU's. It's another thing for Apple to have to support.
When decoding it uses about 5-13% of my total cpu cycles.
The point I'm making is... If it's maxing out my quad core CPU doing a handbrake encode around realtime at a modest bitrate. It's not going to run airplay mirroring in software while getting anything else done.
You don't specify what bitrate or encoding options you were targeting that can affect CPU usage significantly.
Really what are you trying to proof here?
It's a hardware feature. All Macs before the 2011 models can't do it but they still have all their other features they even gained some in Mountain Lion.
I find it a completely logic choice of Apple to only support Macs with Intel Quicksync.
It's completely consistent on supported Macs. If they divide supported Macs between Macs with hardware support and Macs with software than the user experience between the two groups will vary, even more so with the wide range of specs that the software solution will have to support.
This is only a position Apple fanboys can come to after learning it is possible to encode and stream H.264 real-time without fixed-function logic support.
----------
My point is that it's possible not to divide the groups at all.
Almost all unibody Macs and iMacs are capable to do H.264 encoding real-time without bogging the system down so much other work can't be done.
So you're argument is that they should ignore the hardware that was built for almost this exact purpose from the ground up and create a software solution instead?
This is only a position Apple fanboys can come to after learning it is possible to encode and stream H.264 real-time without fixed-function logic support.
But still you don't seem to get the point when the whole idea of Airplay is about mirroring your screen without performance loss. Imagine Airplay support on older Macs through your suggested method. Their would be complaints about heat, noise (fans), battery life and performance overall.
You think it really is no big deal at all to encode over a certain period of time. Maybe this wouldn't have a lot of consequences for iMac users but for laptop users this is important. Encoding the screen in realtime would certainly require a serious amount of CPU usage. Oke, I agree it won't run @ 100% but maybe @ 50% which is more then enough to heat up any computer and consume allot of power.
With the Quicksync method there is only a minimum of added power consumption because there is dedicated hardware to do the job.
If consistency was their goal. Yes.
If planned obsolescence is their goal. No.
----------
I get this, but that fan won't be spinning all that hard since it's only 50% load so it would be barely audible. In fact, you probably couldn't hear it over the noise from the fan in the Apple TV and your TV set, or whatever else you have in your home entertainment center.
As for battery life, I should note it doesn't apply to iMac users, and also that the screen is the largest consumer of power in a modern notebook, not the CPU, so it would not affect battery life as bad as you think.
An older CPU (cause we are talking about older Macs) will definitely consume allot more power and will ramp up the fan because of the added heat.
A CPU @ 50% will most definitely ramp up the fans and create a hot notebook. Have you any experience with MacBooks? It will affect battery life quite noticeably.
I have 2 unsupported Macs, a 2010 MacBook Pro 17" and a 2010 Mac mini, when they have to run 50% load they become quite warm and the fans do rev up (you can clearly hear them) Battery life on the MacBook is also quite allot shorter (where it was 6 hours it becomes 2 or 3). If the Mac would encode it's screen in realtime it would most definitely use more then 50% CPU cause the CPU in the 2010 models was quite weak. (2,66GHz Core 2 duo)
I have owned 2006 cMBP 15, mid-2010 uMBP15, late-2011 uMBP17, and now the rMBP. So I'm quite familiar with how hot they get. Only when loading up CPU to 100% and/or playing games does the notebook get extremely hot. At 50% CPU load the CPU fans are spinning 4000-4500 RPM which is really all that fast or audible.
As for battery life, 2-3 hour sounds normal for a battery with 6 hours normally, but a Quick Sync'd Macbook Pro also has to use power to run the fixed-function logic. Until someone comes up with battery life numbers on Airplay Mirroring, this comparison is moot. Not to mention iMac users who dont have such limitations.
mid-2010 Macbook Pro 17 were quad-core Core i5s for the base model... you have plenty of power to encode and stream a H.264 stream.
This is only a position Apple fanboys can come to after learning it is possible to encode and stream H.264 real-time without fixed-function logic support.
----------
My point is that it's possible not to divide the groups at all.
Almost all unibody Macs and iMacs are capable to do H.264 encoding real-time without bogging the system down so much other work can't be done.
Not everything has to be a conspiracy.
http://gizmodo.com/5929249/why-your-old-mac-cant-use-mountain-lion-mirroring
Did you read through the whole thread? The last 2 pages have been about how you dont need Quick Sync to do what Apple has done.
Also, Quick Sync isn't "on-GPU H.264 encoding"... it's on the CPU.
And the author of that article can't even attempt to use the right "obsolescence" word.
Of course I read the article.
The author of airparrot was speculating on what airplay is using for it's encoding.
Have you actually USED airparrot?
Give it a try!
He had this to say...
"“With AirParrot, we spent a lot more time hand tuning the CPU instructions that power the video conversion,” Stanfill told Cult of Mac. “The H. 264 encoding is actually plenty fast enough on any modern multi-core CPU, but the scaling and colorspace conversion processes are still pretty intensive. We can do 60FPS of 1080p mirroring with only 10-20% CPU usage, which is better than Flash can say for playing 1080p video. The compromise is that on older machines, AirParrot uses a non-trivial amount of CPU, which can result in the fans kicking and the machine getting a little warm… but even with on-GPU AirPlay Mirroring, 2011 MacBook owners will still notice the heat.”
Here is a much better rundown by Ars.
http://arstechnica.com/apple/2012/07/mountain-lion-airplay-mirroring-v-airparrot-fight/
They actually did a shootout.
And at the end...
"AirParrot support just emailed me:
"A future update to AirParrot will use QuickSync capabilities to optimize performance if it is available on the machine."
Last edited:
I said thread, as in THIS thread, not the article.
If you had read the thread then you should already know that AirParrot rolls it's OWN IMPLEMENTATION of H.264 encoding which is most likely TERRIBLE.
What are these guys credentials? Does they really think they can even compete with the x264 team in terms of performance?
Oh look, a x264 developer is playing Call-Of-Duty over a x264 video stream... in 2010. http://x264dev.multimedia.cx/archives/249
It still doesn't take away from the fact that apple are using quicksync for airpay.
You understand this right? I'm not saying they couldn't write a software encoding solution. But it's still not going to be as consistent as using a hardware encoder.
http://arstechnica.com/apple/2012/07/mountain-lion-airplay-mirroring-v-airparrot-fight/
This. Nobody doubts that it is possible to achieve what Apple did via software. Nor is anybody suggesting that it could be more compatible via software. AzN1337c0d3r is implying is that the lack of choice of implementation is due to planned obsolescence or what not. He ignores another choice. Apple made a choice that involved the most simple solution with the least number of compromises with performance. That meant QuickSync support. Now there are arguments that can be made for both sides of the arguments. Who cares about the codec.
None of that changes the fact that Apple chose a specific implementation that relies on hardware. That is the way it is and there is nothing that can be done to change this as it stands. Apple's system relies on hardware because they figured it was the best system. That's why we have other products - to cover scenarios that other people might want. Not surprisingly, Air Parrot involves compromises. Apple did not want to make those compromises in something baked into their product.
No all 2010 MacBook Pros were dual core models. They had hyperthreading but that definitely doesn't make them a quad core.
The dedicated hardware for quicksync really has not allot of power requirements. (It's only a very small part of the CPU/GPU) Much less then a CPU running @ 20%.
You're portraying me as ignorant, which I am not. I simply rejected other's opinions that Apple chose the choice solely because it is the simplest solution with the least compromises. I believe Apple's motive of planned obsolescence were a key factor in picking the Quick Sync implementation over a software or GPU-accelerated solution.
And no one is arguing any of this is false.
Apple is a company, they dont make choices based on what they figure is best for their system. They make choices which are the best for their bottom line.
The problem is people believing that AirParrot has the best encoder out ther and therefore it's impossible to implement something like this without Quick Sync.
That's not even remotely close to true. I just ran an experiment with VLC's screen streaming feature in Windows (something which was removed by Apple in Lion by removing the screen capture API btw) and my (admittedly somewhat powerful) CPU in my sig was able to stream my screen (2560x1600) and encode it with x264 1080p@60 at 3 Mbps using less than 25% of one core. That's <5% CPU usage. Even if you were on a mobile processor, you'd still be looking at something like 10-20% CPU usage.
----------
For some reason I thought all 15/17 inch models since Core i7 were quad-cores as I remembered all the press about it at the time. I will concede I was wrong on this point.
Can you actually cite a source, or are you pulling all of this out your ass? As I recall, the Quick Sync logic uses the x86 decoder... which on a modern day architecture has been the most complex and power-hungry part of the CPU.
Last edited:
http://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
Try Wikipedia or the official Intel site or any other hardware review site.
Quick Sync is dedicated circuitry which means that it consists of a bunch of dedicated transistors with no other function. So no I'm not pulling this out of my ass. The Quick sync logic doesn't use the x86 DEcoder because Quick sync isn't a decoder. It is a hardware ENcoder.
We have know hardware decoders for a long time now but an actual mainstream hardware encoder is new and exclusive for now to the 2011 Sandy Bridge and 2012 Ivy bridge CPUs. (in case of all the available Macs)
That link does not discuss the power usage of Quick Sync? There's no way Quick Sync could even activate if the instructions were not decoded somehow. It's not ALL fixed function hardware, just the parts that do processing.
I compared Airplay on a 2010 2.4 mini to Airplay on a 2011 air. I feel about the same about the two as ArsTechnica in their "fight."
I think Air Parrot works rather well. It's not nearly as bad as some have portrayed in this thread ("crap"). And it has features that AirPlay does not (use the Apple TV as a second monitor for instance). My feelings are it's only $10 and the alternative is.... well, not having the ability at all (other than iTunes).
But, more importantly, AirParrot will be updated to use QuickSync if it is available on the machine. So that little company is apparently able to do what Apple did not: have it use one method for non-QuickSync machines, and QuickSync if it is available.
From the above linked "fight:"
Michael
I think Air Parrot works rather well. It's not nearly as bad as some have portrayed in this thread ("crap"). And it has features that AirPlay does not (use the Apple TV as a second monitor for instance). My feelings are it's only $10 and the alternative is.... well, not having the ability at all (other than iTunes).
But, more importantly, AirParrot will be updated to use QuickSync if it is available on the machine. So that little company is apparently able to do what Apple did not: have it use one method for non-QuickSync machines, and QuickSync if it is available.
From the above linked "fight:"
Michael