Why has Apple still not added the ability to view webms on iOS?
That's especially important for battery-powered devices since the primary WebM codec (VP8) didn't offer a reason to switch from H.264 and would had to be implemented in software rather than using the optimized hardware on the device (this is why YouTube playback performance is so much worse on most systems unless you disable WebM support in your browser).
If iOS can hardware decode H264 but not WebM it actually isn't in the user's interest to support WebM, because it'll reduce incentive to provide H264 versions of content, which means iOS users will experience battery drain faster.
It might not be particularly fair, but it does make sense.
If Apple supported that in browsers I'd bet that Google or other companies would switch their video hosting over, much to the detriment of anyone who watches videos on an iPhone. It's an open standard so clearly they're doing the pro-consumer good thing!
You can contrast this with AV1 which is also a lot of work but which delivers better quality at smaller sizes. It’s not surprising that they picked that option instead.
Very few people care about what format that uses.
"Normal" people do care about their videos starting fast with high image quality. AV1 will deliver them that and deliver it better than H.264 has done. This is true whether they know it or not, whether they care about it or not.
Of course faster load times are nice, they will come, but whether it's through VP8, HEVC, VP1, or something else will take time to shake out. Meanwhile somebody on HN will moan about Apple's monopolistic user hostile refusal to support every single blasted codec released ever.
Good grief, there are even people who still think Apple should have supported Flash, and therefore presumably still support it because the world today would be so much better if Flash was still widely used, or something.
I notice. When I build an application which use video streams and I want to be able to use video without having to worry about the licensing implications. I want video to be royalty-free for all use cases just like all other internet formats and protocols are royalty-free. There is no reason for it not to be.
VP9 gives me that today and it's a shame Apple doesn't have VP9 support. Hopefully they'll announce their timetable for AV1 support soon (and maybe VP9 as a bonus).
https://itunes.apple.com/us/app/cnx-player-ultra-hd-enabled/...
https://ngcodec.com/news/2017/10/21/why-we-are-supporting-vp...
"The installed base is already there for Flash which is an advantage it currently has over HTML5 video"
VP9 decodes faster than H.264 at same picture quality because the bitrate is lower:
https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecod...
It's too bad Apple hasn't turned it on. Intel has included VP9 decoding since Broadwell so a lot of recent Mac laptops have VP9 acceleration hardware ready to go.
That's not the experience I've seen on newer hardware and there are plenty of issues like https://bugs.chromium.org/p/chromium/issues/detail?id=399960..., not to mention extensions like https://github.com/erkserkserks/h264ify / https://github.com/erkserkserks/h264ify-firefox with hundreds of thousands of users.
> VP9 decodes faster than H.264 at same picture quality because the bitrate is lower
That's comparing ffmpeg's decode performance on the CPU using a single clip from one video. What I'm talking about is the difference which hardware acceleration makes, especially since older systems also have older CPUs without the newer instructions used by high-performance software decoders. VP9 implementations have been increasingly optimized over the years but it's really challenging to beat hardware performance even before you consider the power budget.
As a simple example, I opened https://www.youtube.com/watch?v=wbSwFU6tY1c on a 2.13 GHz Intel Core 2 Duo (2010 MacBook Air). That's playing a 1280x720 stream. In all browsers, even with ads blocked by /etc/hosts I had to wait ~20 seconds for the 80+% CPU from the YouTube JavaScript to settle down before starting playback. In Safari, that video takes between 3 and 8% CPU usage with no dropped frames. In Chrome, that's 80-120% CPU usage and about a 5% dropped frame rate.
Firefox is interesting: it ran at about 15-20% CPU usage, which is worse than Safari but still much better than Chrome. I thought that was odd but stats for nerds showed why: Firefox was using H.264. After using media.mediasource.webm.enabled to forcibly enable webm, it started using VP9 and that meant ~40% CPU with bursts up to about 80%. While that's clearly much better than the Chrome experience it's still a full order of magnitude more CPU than Safari's hardware path.
Remember, I'm not saying that VP9 is horrible but rather than hardware support is a really big deal and optimized video playback in general has non-trivial costs. Apple made a big investment in HEVC and it doesn't surprise me that they're investing in the next generation rather than spending time on the current generation since the fixed costs for tuning, testing, security, etc. are the same whether 100% or 5% of your customers use it.
Works fine for me at 1080p VP9 on a mid-2014 Macbook Pro. 720p VP9 also works fine in VLC on my iPhone 7. Haven't tried 1080p on the phone. It doesn't have the resolution for it anyway. 720p AV1 will probably work on the phone as well (AV1 decode is about 1.5x the complexity of VP9).
> What I'm talking about is the difference which hardware acceleration makes
So it's time to get Apple to enable the VP9 acceleration present in their latest models (around 2015 and later).
But don't worry about it. AV1 is coming and everyone is finally on-board with royalty-free video. The bad old days are nearly over.
How do you know what's in the users interest? A choice between "Video playing" vs. "Video not playing" is pretty obvious to me. (And I am a user too)
If battery really is a concern (assuming it is), just make it an option not to play videos if they require software decoding.
Besides that, users usually (an assumption I made, just as you did) don't watch lengthy videos (1-2 hours) on an iOS device.
Contrary to your point about not watching on iOS, I, and everyone I know, watch all content on an iOS device, both in the living room and on the go.
There is certainly a segment of the market that is using misc devices or “casting” to USB sticks plugged into TVs, but the 4K TV owning cord cutters I know tend to also own iPhones and use Apple TVs.
We saw this shift happen even more when iOS (and TvOS) gained SSO across apps with the “TV” app as indexer, and another bump when Amazon Prime released.
If you watch in the living room (on TV) you are not watching it on the iOS device. By that I mean the screen of the iOS device. Being in the living room, watching on TV, means you have no battery issue. Watching on your device means literally that, watching it on your device with your devices' screen. Not some casting or streaming to other displays.
If we ignore YouTube, which Google controls to their own benefit, what’s the percentage of WebM/VP9 versus H264/H265?
H264 is used in other places in the electronics industry. That’s one of the reasons Apple picked it. Isn’t it the format most digital cameras record video in?
WebM/VP9 is used by... Google. And Wikipedia (who won’t use something with patent licensing). Is there anything else big?
Basically everyone else uses H264 like Apple since it was the designated successor to MPEG2.
In this case, Apple went with the industry standard. Google is the odd man out.
So why should Apple have to bend to Google’s whim here and implement WebM/VP9?
Why shouldn’t Google just fix their site?
No, browsers and hardware manufacturers have implemented VP9 because it has better licensing terms than H.264 and especially better than HEVC. HEVC was released at around the same time as VP9 and yet today VP9 has double the installed base of HEVC: https://ngcodec.com/news/2017/10/21/why-we-are-supporting-vp...
> In this case, Apple went with the industry standard.
No. When it comes to the web the industry standard is royalty-free formats and protocols: https://www.w3.org/Consortium/Patent-Policy-20170801/
Video formats which require a patent licensing fee (like H.264 and HEVC) have been an anomaly.
> Why shouldn’t Google just fix their site?
Because VP9 outperforms H.264: https://medium.com/netflix-techblog/more-efficient-mobile-en...
VP9 just works better: https://youtube-eng.googleblog.com/2015/04/vp9-faster-better...
This isn’t like Mozilla, who only makes a web browser.
Apple will be adding support for AV1. Like VP9, AV1 is royalty-free. The Alliance for Open Media has been so effective (even before AV1's release) and HEVC's licensing has been so terrible that MPEG is starting to question whether it can survive as an organization:
http://blog.chiariglione.org/a-crisis-the-causes-and-a-solut...
Royalty-free video formats are simply a better way to go.
WebM was released in 2010. VP9 is from ‘12/‘13.
H264 was already the web video standard when WebM/VP9 came along.
I take issue with Google trying to force everyone over to their format and removing support for higher resolution H264. They crippled what used to work for me to push their agenda. And because it’s license free I’m supposed to be good with it.
This is exactly the kind of stuff people used to get pissed at MS or Apple for.
But it’s Google, and people love Chrome. So this is good and Apple is the one not going with the ‘standard’ that ‘everyone else’ is using.
And, yes, it was not Google's finest hour, especially when they strung Mozilla promising to disable H.264 in Chrome but never actually shipping it (remember https://brendaneich.com/2012/03/video-mobile-and-the-open-we...).
The service that also provides H264 versions of its content, you mean? Which is the point I already made.
> How do you know what's in the users interest? [...] If battery really is a concern (assuming it is)
Well, Apple is heavy-handed with its users. They make a lot of assumptions about what is best for them, and this is one of them.
> don't watch lengthy videos (1-2 hours) on an iOS device.
I suspect Netflix would disagree with you.
Netflix on an iPhone? Probably not. At least not holding it in your hand for 2 hours.
Do you have data to support this or are you just assuming that your personal tastes are universal? I see quite a few people watching videos on phones or tablets – ever see parents loading up their kid’s iPad before a flight?
With 80% on a "big" device.
I also watch videos, but "video" is not a movie or series. Video sounds more like 15 min. max and/or not "cinematic".
Obviously. But that's not how Apple works. You do things their way, or you get an Android phone/Windows laptop. They make the choices for users, and judging by market share a very solid number of people are very content with that arrangement.
http://www.streamingmedia.com/Articles/News/Online-Video-New...
Apple might never add VP9 support but 4K video from YouTube will work again once YouTube starts encoding to AV1 and Apple adds AV1 support.
[1] i.e. Vorbis, Theora, Flac, matroska containers, etc. Opus is supported in Safari for WebRTC because they have to, but is completely unavailable in other contexts.
Apple developed Apple Lossless ("ALAC"), a different, unrelated [4] format, which was fairly similar to FLAC, but different in some minor ways (paraphrasing the FLAC dev's own words [4]).
[1] https://en.wikipedia.org/wiki/Audio_Lossless_Coding [2] https://en.wikipedia.org/wiki/Lossless_predictive_audio_comp... [3] http://elvera.nue.tu-berlin.de/files/0737Liebchen2005.pdf [4] https://hydrogenaud.io/index.php/topic,32111.msg279843.html#...
Also, FLAC file decoding is horribly slow - compared to the FOSS reference decoder -, because for some reason the whole file is scanned through on the first read when using the AudioFile APIs (AudioFileReadPacketData). (I’m gonna make a demonstration project for this and send them a bugreport tomorrow.)
With Apple’s AudioFile API you can decide whether you want the decompressed PCM samples, or the underlying compressed packets. You can get better energy efficiency if you offload the decompression step to the dedicated coprocessor. The difference is smaller than with hardware vs software h.264 decoding, but there is a difference.
(For lossy codecs this also makes sense when you want to forward the compressed packets to a wireless speaker in order to avoid lossy recompression on Bluetooth transmission.)