The issue is VP9 is googles attempt to workaround patents because they don't believe they should pay to use them. It's already been discussed that that VP9 may just be a ripoff of H.264 and can have intellectual property issues. Apple, for effciency of mobile devices, desires a standard that can be decoded in hardware for performance and battery life. It pays into the consortium to be a legitimate partner in the development of open source technology where companies work together for the common good.
Apple doesn't support H.265 support either. Why? Like Google they refuse to pay for it. The royalties and open patent questions surrounding it are a problem. There's also no evidence whatsoever that VP9 is treading on IP controlled by the H.264 consortium AFAIK. Did you read something different?
1) The technically support H.265 in iOS when both devices are an iPhone 6(?) series or better -and- when both are using cellular for FaceTime video calls. I'd like to think they did that to work out any issues before launching it for high-bitrate files, but the truth probably falls closer to not applying to high-bitrate video because of royalty licensing, whereas FaceTime calls are license and cost-free between users.
2) Whether there is evidence or not, the threat of VP8+ infringing on MPEG and other patent holder's algorithms and codes are still very real. As we've seen with patent trolls, you can sit on even an unused patent for many years and then sue them in the Eastern District of Texas for royalties on every device ever sold. That said, every major company that designs processor architecture supports HW-based VP9 decoding, with some chips supporting HW-based VP9-encoding. Then you have AV1 coming as an extension of VP9 later this year with major backers like Amazon, Netflix, and Alphabet (YouTube) you probably have most of the video traffic being served, so that looks promising.
MPEG already settled with Google over VP8+ in 2015. That made all licensees of VP8 and /or WebM completely safe from any claim of patent infringement by the MPEG-LA H.264 consortium. That's why Microsoft finally had no excuse for not using VP8+ and took a license from Google for their Edge browser. Safari is the last hold-out among major browsers isn't it?
There's absolutely no way that MPEG settling with Google in 2015 means that there can be no other issues from MPEG or from any other potential patent holder. It's illogically to make any such claim.
Well you are correct that anything is possible, even if unlikely. Apple doesn't seem to typically avoid including features over the possibility that there might be someone someday that sues them for infringing some patent potentially connected to it. So I don't personally think Apple's decision (so far) not to support Google's royalty-free VP9 is due to that either.
There's absolutely no way that MPEG settling with Google in 2015 means that there can be no other issues from MPEG or from any other potential patent holder. It's illogically to make any such claim.
Well you are correct that anything is possible, even if unlikely. Apple doesn't seem to typically avoid including features over the possibility that there might be someone someday that sues them for infringing some patent potentially connected to it. So I don't personally think Apple's decision (so far) not to support Google's royalty-free VP9 is due to that either.
From what I've seen since Apple's rebirth is that they're overly cautious about potential legal pitfalls because of their excessive mindshare, and they still sued out the ass for the most ridiculous shit. Today I saw an article about Apple having a monopoly on iOS app on the iOS App Store, and then a couple weeks ago it was suing Apple because an idiot driver decided to use FaceTime.
The issue is VP9 is googles attempt to workaround patents because they don't believe they should pay to use them. It's already been discussed that that VP9 may just be a ripoff of H.264 and can have intellectual property issues. Apple, for effciency of mobile devices, desires a standard that can be decoded in hardware for performance and battery life. It pays into the consortium to be a legitimate partner in the development of open source technology where companies work together for the common good.
Apple doesn't support H.265 support either. Why? Like Google they refuse to pay for it. The royalties and open patent questions surrounding it are a problem. There's also no evidence whatsoever that VP9 is treading on IP controlled by the H.264 consortium AFAIK. Did you read something different?
1) The technically support H.265 in iOS when both devices are an iPhone 6(?) series or better -and- when both are using cellular for FaceTime video calls. I'd like to think they did that to work out any issues before launching it for high-bitrate files, but the truth probably falls closer to not applying to high-bitrate video because of royalty licensing, whereas FaceTime calls are license and cost-free between users.
2) Whether there is evidence or not, the threat of VP8+ infringing on MPEG and other patent holder's algorithms and codes are still very real. As we've seen with patent trolls, you can sit on even an unused patent for many years and then sue them in the Eastern District of Texas for royalties on every device ever sold. That said, every major company that designs processor architecture supports HW-based VP9 decoding, with some chips supporting HW-based VP9-encoding. Then you have AV1 coming as an extension of VP9 later this year with major backers like Amazon, Netflix, and Alphabet (YouTube) you probably have most of the video traffic being served, so that looks promising.
MPEG already settled with Google over VP8+ in 2015. That made all licensees of VP8 and /or WebM completely safe from any claim of patent infringement by the MPEG-LA H.264 consortium. That's why Microsoft finally had no excuse for not using VP8+ and took a license from Google for their Edge browser. Safari is the last hold-out among major browsers isn't it?
There's absolutely no way that MPEG settling with Google in 2015 means that there can be no other issues from MPEG or from any other potential patent holder. It's illogically to make any such claim.
Well you are correct that anything is possible, even if unlikely. Apple doesn't seem to typically avoid including features over the possibility that there might be someone someday that sues them for infringing some patent potentially connected to it. So I don't personally think Apple's decision (so far) not to support Google's royalty-free VP9 is due to that either.
I think technicalities may be more effective on Apple's decision than patent risks. Intel Quick Sync Video has only a partial VP9 support in Skylake, and 10 bit decode vs. 8-bit encode for VP9 vs. 10 bit decode/encode for H.265 in Kaby Lake. https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
Apple has also other realms to consider, such as iTunes and AppleTV content.
There are a lot of third party and open source utilities that do a lot of video conversions.
Obviously, but they're not much help when the object of the exercise is to add audio to an existing video file and pass it on in the original format. I don't think you'd be very pleased with converting every single video coming across your desk to a new format to work on it then have to convert it BACK again for the system to use it.
Try to get these instead of questioning Apple's policies.
Wow. That topped the list of most Fanboy-ish thing I've read this week. Counselling a user to not question the supplier not only sounds like blind faith but also ignores the fact that the supplier depends on the user for feedback.
OBVIOUSLY we work around the things that impede our work. That means that the next "workaround" might be to dump Apple, which would be disappointing to me. It already happened in the MC suites.
I am comfortable with Apple's broad inventory of both professional and consumer-level codecs. For a couple of rip-off, non-standard, unsupported, abandoned wild codecs third party utilities always do the job...
It's encouraging that the current situation is working for you, but doesn't speak to the differences in workflows and integration requirements that cause significant obstacles for others.
ProRes largely eliminated the need for the Animation CODEC, but converting existing material isn't a solution when the broadcast servers don't support it. Nor can ProRes be adopted for new material. Obviously a TV station isn't going to replace a major portion of the air chain just because Apple decides to stop supporting a common CODEC. It's easier, cheaper and less disruptive to just quit buying Apple workstations.
Likewise having to remux anything that contains a DTS audio stream, even if I'm not using it and the file also includes Dolby and AAC alternatives, is a major time-suck and adversely affects the value of the work I produce. This particular issue is unique to my new MacBook Pro (our other Macs do not exhibit this problem, even with identical software versions), but it's still a disruption caused by Apple, and because Apple treats every issue like a life-or-death secret, there's no way to know if it's a bug that will be fixed or if this machine is just the first to include a change that will be included in all new Macs from now on.
There are a lot of third party and open source utilities that do a lot of video conversions.
Obviously, but they're not much help when the object of the exercise is to add audio to an existing video file and pass it on in the original format. I don't think you'd be very pleased with converting every single video coming across your desk to a new format to work on it then have to convert it BACK again for the system to use it.
What you need is an utility that supports the container format of the original file. You add the audio track then save the file in the original container format. If it is AVI then you save in AVI. If there is no such an utility then the original format is a bad choice, obviously. Why would that be Apple's fault?
Try to get these instead of questioning Apple's policies.
Wow. That topped the list of most Fanboy-ish thing I've read this week. Counselling a user to not question the supplier not only sounds like blind faith but also ignores the fact that the supplier depends on the user for feedback.
Then submit your feedback to Apple http://apple.com/feedback. No tech company discusses its engineering decisions in open public. Ever... Besides, questioning Apple's policies will not resolve your mundane tech problem of adding an audio track to a movie file and saving back in the original format.
Likewise having to remux anything that contains a DTS audio stream, even if I'm not using it and the file also includes Dolby and AAC alternatives, is a major time-suck and adversely affects the value of the work I produce. This particular issue is unique to my new MacBook Pro (our other Macs do not exhibit this problem, even with identical software versions), but it's still a disruption caused by Apple, and because Apple treats every issue like a life-or-death secret, there's no way to know if it's a bug that will be fixed or if this machine is just the first to include a change that will be included in all new Macs from now on.
Get a Quicktime Player 7 and delete the DTS audio track. Then Quicktime will use Dolby or AAC version depending on the layering. You can also enable/disable tracks with Quicktime Player 7 instead of deleting. If your other Macs don't expose the same problem they most probably have some third party Quicktime plug-ins that don't exist in your new Macbook Pro. Apple never treats your mundane usage problems like a life-or-death secret, it provides a huge knowledge base http://support.apple.com/
There's absolutely no way that MPEG settling with Google in 2015 means that there can be no other issues from MPEG or from any other potential patent holder. It's illogically to make any such claim.
Well you are correct that anything is possible, even if unlikely. Apple doesn't seem to typically avoid including features over the possibility that there might be someone someday that sues them for infringing some patent potentially connected to it. So I don't personally think Apple's decision (so far) not to support Google's royalty-free VP9 is due to that either.
From what I've seen since Apple's rebirth is that they're overly cautious about potential legal pitfalls because of their excessive mindshare, and they still sued out the ass for the most ridiculous shit. Today I saw an article about Apple having a monopoly on iOS app on the iOS App Store, and then a couple weeks ago it was suing Apple because an idiot driver decided to use FaceTime.
There's a group of companies that has splintered off from MPEG-LA that says they're going to go after end user royalties for H.265. Ah, checked my old post, HEVC Advance is the group. H.265 was originally in the specs for the iPhone 6S, then the HEVC Advance threats about royalties came out and suddenly all mention of H.265 was pulled from everything.
A quick check and HEVC Advance announced a new 'initiative' on Nov. 22nd. It'll come down to how much they want to slug companies like Apple for it:
BOSTON – (November 22, 2016) – HEVC Advance, an independent licensing administrator, today
announced a major software policy initiative to rapidly accelerate widespread HEVC/UHD adoption in
consumer mobile devices and personal computers. Under the software initiative, HEVC Advance will not
seek a license or royalties on HEVC functionality implemented in application layer software downloaded to
mobile devices or personal computers after the initial sale of the device, where the HEVC encoding or
decoding is fully executed in software on a general purpose CPU. Examples of the types of software within
the policy include browsers, media players and various software applications.
What you need is an utility that supports the container format of the original file. You add the audio track then save the file in the original container format.
That's a valid concept but it won't work because I have to be able to see the video in order to create the audio.
If there is no such an utility then the original format is a bad choice, obviously.
That assumes we get to arbitrarily choose the format. As I mentioned before, our choices are limited to whatever the equipment in the air chain will support. Some of that equipment is six or seven years old and isn't likely to replaced anytime soon. While each device in the chain supports more than one file format, not all of the choices are available on every system/device, so the options are further limited to only those that are common to all of them. It's not an insurmountable problem or anything, but it does mean that changing formats needs to be done carefully.
No tech company discusses its engineering decisions in open public. Ever...
Maybe not, but the suppliers of our more esoteric equipment WILL tell us whether a missing or changed function is unintended or a deliberate choice. That way we know whether we can just wait for a "fix" or if we have to find a more permanent alternative.
Besides, questioning Apple's policies will not resolve your mundane tech problem of adding an audio track to a movie file and saving back in the original format.
Perhaps our definitions of the term differ, but I don't consider having a production workflow turned on its head "mundane." It may seem like it when worded the way you put it, but that's an over-simplification of the actual situation.
Neither is it a "tech problem" in the traditional meaning of that phrase. Yes, it is obviously a technical issue that's causing the problem, but it isn't a case of accidental incompatibilities or something being broken or any of the other myriad unintentional road blocks. It's the direct result of Apple choosing not only to stop including a particular CODEC but to wipe it from the face of the planet.
Maybe there's a valid technical reason for Apple dropping the Animation CODEC, but I can't imagine what it would be. It's not like it requires continuing attention -- it's a CODEC. It seems to be another case of Apple deciding that something else is better and cutting off access to pre-existing alternatives to "encourage" adoption of the new thing, in this case, ProRes.
As other people using Apple equipment in so-called "pro" environments have complained in other threads (most recently about the port changes on the new MacBook Pro, which I actually welcomed and appreciate), the problem isn't change per se, it's that these machines aren't used in isolation. They're part of a larger chain, and updates to the rest of the chain happen slowly and are often not within the direct control of the affected user.
If your other Macs don't expose the same problem they most probably have some third party Quicktime plug-ins that don't exist in your new Macbook Pro.
You'd think so, right? Yet I can't for the life of me figure out WHAT is present on the other machines that isn't on the new one. I haven't installed anything on them that isn't on the new one. That leads me to suspect it's one of a few things:
1. Even though the version numbers are the same, the OS install includes different components on different machines. Something is missing, is excluded, or otherwise differs when installing on the new MacBook Pro compared to the old MacBook Pro, Mac Pro and Mac mini.
2. There's a hardware incompatibility. I had no idea such issues even exist until Avid told me I can't use a newer version of Pro Tools on an older Mac because their video engine doesn't work with C2D CPUs. Maybe there's an issue with the latest CPUs and DTS? Seems unlikely, but then so did the Pro Tools issue.
3. Maybe the order in which software is installed matters? At first I thought maybe a "manual" install of the OS includes components that aren't included from the factory, but the problem persisted even after wiping the machine and reinstalling everything, including the OS, from scratch. There's nothing on the mini that isn't also on this machine, but they may have been installed in a different order.
I'll keep working on it, but for now it takes a back seat to the much more pressing issues with iTunes having trouble with mp3 files. Sigh...
This is likely a play by Google to drive the adoption of Chrome. I got rid of that pathetic browser a long time ago freeing up substantial bandwidth and restoring good performance to my iPhone.
I don't use YouTube for much other than how to videos and repair projects. I would rather go to a legitimate source for content such as iTunes, Amazon, Netflix and DIRECTV. The 4K support by YouTube is a non-issue for me.
And if people stop watching YouTube, Google will step up to the plate.
I am certain that Facebook supports H.264 and that's far more important than whether YouTube does.
YouTube doesn't have that much clout. H.264 is standard and legal. VP9 is an attempt again by Google to usurp intellectual property. It is pathetic to watch a company like them resort to these types of unsavory and frankly pathetic practices.
Once Facebook or Amazon develops an competitive model, I won't be using YouTube at all.
How is YouTube not a legitimate source for content? There's paid content on it. Networks and studios support it with official content. Record labels and music publishers support it with official content.
You make some pretty significant claims here about how few users YouTube has, and how little influence it has over the market. I'd love to see some reports and studies detailing how you got there.
macplusplus said: Get a Quicktime Player 7 and delete the DTS audio track.
Well here's an interesting development. I installed Quicktime 7 Pro (which is NOT installed on the other machines) and now files with DTS tracks play fine. I didn't do anything at all to the files themselves, all I did was install QT7Pro. Quicktime and iTunes don't recognize the DTS track, but at least they now just ignore it and play the file rather than treating it as corrupt.
As a test I transcoded a file with DTS audio only, no other audio, and Quicktime sees it as video only with audio at all. That's what the other machines do too, and I can live with it.
VP9 is from On2, which Google acquired long ago, has a history of giving us crap marketing numbers about how good its codec is. This has continued even after it is under Google.
While VP9 has improved a lot over the years, it really is still in the same league as H.264. When they claim they are 20 or 30% better then H.264, that is because there are multiple levels and standard within H.264, and there are multiple encoders for it as well. For VP9 there are two, But they mostly refer to Google's official implementation.
If you consider the best of H.264 encoder, the x264, and with tuned parameters, it will be roughly the same quality as VP9 at same bitrate.
But you get HW acceleration in almost all current Smartphone and Computers.
The Youtube videos embedded into webpages (like this one) play in 4K in Safari perfectly fine. (I just tried it myself). It's only when you watch on youtube.com that the 4K option is not shown. So technically, Apple is right: Youtube/Google made a conscious decision to change to the VP9 format on Youtube.com. That's not something Apple can control. I think that's very unkind of Google, I hope they do work things out.
The Youtube videos embedded into webpages (like this one) play in 4K in Safari perfectly fine. (I just tried it myself). It's only when you watch on youtube.com that the 4K option is not shown. So technically, Apple is right: Youtube/Google made a conscious decision to change to the VP9 format on Youtube.com. That's not something Apple can control. I think that's very unkind of Google, I hope they do work things out.
What appears to be Google's shift to the VP9 codec for delivering 4K video on the YouTube homepage is preventing Safari users from watching videos uploaded to the service since early December in full 4K resolution, but not from viewing webpage-embedded videos in the same resolution.
We’ve been prevented from watching videos in 1080p in a QuickTime window for years. They stopped converting into MP4 long ago. Not that I really care about the resolution; I just wish Click2Flash still worked so that I didn’t have to use YouTube’s atrocious UI.
[...] Youtube/Google made a conscious decision to change to the VP9 format on Youtube.com. That's not something Apple can control.
No, Apple can't control the format of content on YouTube, but Apple COULD include support for VP9 in Safari. Apple made a conscious decision not to support it.
For all I know there may well be a compelling reason not to include VP9 support in Safari, but it's not fair to disparage the source of a video for providing it in a format that a particular playback system can't play, especially when that particular playback system is only used by a small minority of viewers. CODECs are a two-way street, with both suppliers and playback software developers having a share of the responsibility for making sure users enjoy a painless experience.
In this case, Google made a choice that they feel best suits the interests of the supply side of the equation, and Apple has made a choice that they feel best suits the playback side. It's an unfortunate outcome, but neither party is a villain.
(EDIT: Since 4K YouTube videos DO work in Safari when embedded, it's possible this is just a temporary hiccup caused by some code that wasn't designed for this particular development and may be updated to accommodate it in the future.)
""[Google] has seemingly made a conscious decision to not stream H.264 4K video to Apple users from the YouTube homepage, when it clearly could if it chose to.""
Isn't that the kind of behavior the EU has been known to frown upon? Not doing something it used to do, in order to favor one of its own products, Chrime?
No, Apple can't control the format of content on YouTube, but Apple COULD include support for VP9 in Safari. Apple made a conscious decision not to support it.
Apple doesn't support VP9 for the opposite of the reason that Google refuses to support MP4. Why use anything proprietary of Google's?
No, Apple can't control the format of content on YouTube, but Apple COULD include support for VP9 in Safari. Apple made a conscious decision not to support it.
Apple doesn't support VP9 for the opposite of the reason that Google refuses to support MP4. Why use anything proprietary of Google's?
Comments
Apple has also other realms to consider, such as iTunes and AppleTV content.
Wow. That topped the list of most Fanboy-ish thing I've read this week. Counselling a user to not question the supplier not only sounds like blind faith but also ignores the fact that the supplier depends on the user for feedback.
OBVIOUSLY we work around the things that impede our work. That means that the next "workaround" might be to dump Apple, which would be disappointing to me. It already happened in the MC suites.
It's encouraging that the current situation is working for you, but doesn't speak to the differences in workflows and integration requirements that cause significant obstacles for others.
ProRes largely eliminated the need for the Animation CODEC, but converting existing material isn't a solution when the broadcast servers don't support it. Nor can ProRes be adopted for new material. Obviously a TV station isn't going to replace a major portion of the air chain just because Apple decides to stop supporting a common CODEC. It's easier, cheaper and less disruptive to just quit buying Apple workstations.
Likewise having to remux anything that contains a DTS audio stream, even if I'm not using it and the file also includes Dolby and AAC alternatives, is a major time-suck and adversely affects the value of the work I produce. This particular issue is unique to my new MacBook Pro (our other Macs do not exhibit this problem, even with identical software versions), but it's still a disruption caused by Apple, and because Apple treats every issue like a life-or-death secret, there's no way to know if it's a bug that will be fixed or if this machine is just the first to include a change that will be included in all new Macs from now on.
Then submit your feedback to Apple http://apple.com/feedback. No tech company discusses its engineering decisions in open public. Ever... Besides, questioning Apple's policies will not resolve your mundane tech problem of adding an audio track to a movie file and saving back in the original format.
lorin schultz said: Get a Quicktime Player 7 and delete the DTS audio track. Then Quicktime will use Dolby or AAC version depending on the layering. You can also enable/disable tracks with Quicktime Player 7 instead of deleting. If your other Macs don't expose the same problem they most probably have some third party Quicktime plug-ins that don't exist in your new Macbook Pro. Apple never treats your mundane usage problems like a life-or-death secret, it provides a huge knowledge base http://support.apple.com/
A quick check and HEVC Advance announced a new 'initiative' on Nov. 22nd. It'll come down to how much they want to slug companies like Apple for it:
http://www.hevcadvance.com/pdfnew/SoftwarePressReleaseNEWNov-22-2016.pdf
BOSTON – (November 22, 2016) – HEVC Advance, an independent licensing administrator, today announced a major software policy initiative to rapidly accelerate widespread HEVC/UHD adoption in consumer mobile devices and personal computers. Under the software initiative, HEVC Advance will not seek a license or royalties on HEVC functionality implemented in application layer software downloaded to mobile devices or personal computers after the initial sale of the device, where the HEVC encoding or decoding is fully executed in software on a general purpose CPU. Examples of the types of software within the policy include browsers, media players and various software applications.
That assumes we get to arbitrarily choose the format. As I mentioned before, our choices are limited to whatever the equipment in the air chain will support. Some of that equipment is six or seven years old and isn't likely to replaced anytime soon. While each device in the chain supports more than one file format, not all of the choices are available on every system/device, so the options are further limited to only those that are common to all of them. It's not an insurmountable problem or anything, but it does mean that changing formats needs to be done carefully.
I do that so often that I fear they may have my name blocked by now!
Maybe not, but the suppliers of our more esoteric equipment WILL tell us whether a missing or changed function is unintended or a deliberate choice. That way we know whether we can just wait for a "fix" or if we have to find a more permanent alternative.
Perhaps our definitions of the term differ, but I don't consider having a production workflow turned on its head "mundane." It may seem like it when worded the way you put it, but that's an over-simplification of the actual situation.
Neither is it a "tech problem" in the traditional meaning of that phrase. Yes, it is obviously a technical issue that's causing the problem, but it isn't a case of accidental incompatibilities or something being broken or any of the other myriad unintentional road blocks. It's the direct result of Apple choosing not only to stop including a particular CODEC but to wipe it from the face of the planet.
Maybe there's a valid technical reason for Apple dropping the Animation CODEC, but I can't imagine what it would be. It's not like it requires continuing attention -- it's a CODEC. It seems to be another case of Apple deciding that something else is better and cutting off access to pre-existing alternatives to "encourage" adoption of the new thing, in this case, ProRes.
As other people using Apple equipment in so-called "pro" environments have complained in other threads (most recently about the port changes on the new MacBook Pro, which I actually welcomed and appreciate), the problem isn't change per se, it's that these machines aren't used in isolation. They're part of a larger chain, and updates to the rest of the chain happen slowly and are often not within the direct control of the affected user.
You'd think so, right? Yet I can't for the life of me figure out WHAT is present on the other machines that isn't on the new one. I haven't installed anything on them that isn't on the new one. That leads me to suspect it's one of a few things:
1. Even though the version numbers are the same, the OS install includes different components on different machines. Something is missing, is excluded, or otherwise differs when installing on the new MacBook Pro compared to the old MacBook Pro, Mac Pro and Mac mini.
2. There's a hardware incompatibility. I had no idea such issues even exist until Avid told me I can't use a newer version of Pro Tools on an older Mac because their video engine doesn't work with C2D CPUs. Maybe there's an issue with the latest CPUs and DTS? Seems unlikely, but then so did the Pro Tools issue.
3. Maybe the order in which software is installed matters? At first I thought maybe a "manual" install of the OS includes components that aren't included from the factory, but the problem persisted even after wiping the machine and reinstalling everything, including the OS, from scratch. There's nothing on the mini that isn't also on this machine, but they may have been installed in a different order.
I'll keep working on it, but for now it takes a back seat to the much more pressing issues with iTunes having trouble with mp3 files. Sigh...
You make some pretty significant claims here about how few users YouTube has, and how little influence it has over the market. I'd love to see some reports and studies detailing how you got there.
As a test I transcoded a file with DTS audio only, no other audio, and Quicktime sees it as video only with audio at all. That's what the other machines do too, and I can live with it.
While VP9 has improved a lot over the years, it really is still in the same league as H.264. When they claim they are 20 or 30% better then H.264, that is because there are multiple levels and standard within H.264, and there are multiple encoders for it as well. For VP9 there are two, But they mostly refer to Google's official implementation.
If you consider the best of H.264 encoder, the x264, and with tuned parameters, it will be roughly the same quality as VP9 at same bitrate.
But you get HW acceleration in almost all current Smartphone and Computers.
No, Apple can't control the format of content on YouTube, but Apple COULD include support for VP9 in Safari. Apple made a conscious decision not to support it.
For all I know there may well be a compelling reason not to include VP9 support in Safari, but it's not fair to disparage the source of a video for providing it in a format that a particular playback system can't play, especially when that particular playback system is only used by a small minority of viewers. CODECs are a two-way street, with both suppliers and playback software developers having a share of the responsibility for making sure users enjoy a painless experience.
In this case, Google made a choice that they feel best suits the interests of the supply side of the equation, and Apple has made a choice that they feel best suits the playback side. It's an unfortunate outcome, but neither party is a villain.
(EDIT: Since 4K YouTube videos DO work in Safari when embedded, it's possible this is just a temporary hiccup caused by some code that wasn't designed for this particular development and may be updated to accommodate it in the future.)
https://developers.google.com/cast/docs/media
https://support.google.com/youtube/troubleshooter/2888402?hl=en
https://support.google.com/chromebook/answer/183093?hl=en