Hacker News Reader

Comment by std_throwaway | Hacker News Reader

Mac users have long known that using Safari extends their battery life. This change by YouTube probably improves it further.

View on HN

I always hear about Safari being described as "the new IE", but after switching back to a Macbook I've tried to force myself to stay on Safari as a default browser and it's pretty great from a user perspective.

It saves an incredible amount of battery life over Chrome (which makes me that much more weary of Electron apps eating up battery and memory at idle). Is there any specific architecture decision by Safari that enables those battery savings?

AFAIK the difference is Safari is not as secure as Chrome. Chrome's multi-process security comes at a cost in that pretty much everything a webpage wants/needs to do needs to be shuttled between processes. All network request, all disk io, all graphics happen in other processes. The communication overhead between processes is the difference in CPU usage. It's also why Chrome has 10x less code execution bugs than Safari. Note: Chrome doesn't have 10x less bugs. It has the same number of bugs. It's just by category of bugs it has 10x less code execution bugs.

http://www.cvedetails.com/product/2935/Apple-Safari.html?ven...

http://www.cvedetails.com/product/15031/Google-Chrome.html?v...

I'm only guessing that as Firefox goes multi-process for security reasons the same thing will happen. Their CPU usage will go up because of the overhead of cross process communication but their code execution bug percentage will go down

WebKit2 behaves in the same way with regards to the points mentioned above. The sandboxed content process(es) are responsible for network, IO, layout, etc. The UI process (normally, the browser process) serves only as a broker for developer decision making and final drawing of the laid out content.

See https://trac.webkit.org/wiki/WebKit2#ProcessArchitecture

AFAIK WebKit2 does not use a separate process for graphics. Graphics calls go directly into whatever api is appropriate (CoreGraphics, OpenGL).

Where as Chrome that's not the case, all OS/Driver level graphics happen in the GPU process. That means all data has to be shuttled from the process that wants to display the data to the GPU process. Even video for example gets decoded in a secure process (because there might be exploitable bugs in the codecs) then that data has to be shuttled to the GPU process so it can be composited with the page. The directives of compositing happen in the render process (the webpage) but eventually have to translated to graphics commands that happen in the GPU process.

None of this is true in WebKit2 AFAIK and is one of the many reasons it has so many move code exploit bugs (15x actually for 2016).

Safari has been multi process for ages now (several years). I don't think that's the difference. I think Safari simply errs on the side of better resource consumption where Chrome's highest priority is cutting edge shinies for web front end devs and being as fast as possible at the cost of everything else.

One example of this is where Safari will suspend tabs (as in slow them down or freeze them while keeping them in memory) you haven't used in 15+ minutes that aren't playing music for anything. Effectively, this means that Safari's total power impact is only that of the 2-4 tabs you're currently actively using instead of how ever many you actually have open. It's a bit nicer than something like The Great Suspender though, since it doesn't just trash the loaded pages and force you to reload upon visiting said tabs.

If you're using an adblocker based on WebKit Content Blockers, that can have an impact too. They're much more efficient than even uBlock and add almost no additional CPU or RAM usage to web browsing, meaning you fully reap all the savings of blocking ads and egregious JS.

While technically true for Safari, all these advantages are true if you develop your own application using WKWebView. Each web view will consume its own process up to a point, then some processes will be reused; inactive processes will throttle down activity and suspect. The WebKit2 architecture is a lot more efficient in its memory managed as well. It's a shame so many browsers went with Blink rather than use WebKit2, mostly for political reasons.

I think the bigger problem with WebKit-based browsers on platforms other than macOS is the frequency of updates. For example, I find GNOME Web on Linux/*BSD perfectly suited for my own web browsing, but depending on the distribution you're using updates can be fewer between than even Safari's once-per-year big updates and far more infrequent than Safari Technology Preview's or Chrome's update schedule.

There aren't really any good WebKit-based options on Windows, though. IIRC Midori runs on Windows but is GTK based and feels out of place.

I'm not sure it's Safari per se. Safari is quite a "thin" layer around WebKit2. By "thin", I mean if you remove all the iCloud stuff, bookmarks, etc. Tab management intelligence is performed by WebKit2 backend process. So I think it's more of a testament to WebKit2 architecture. It's a real shame there is no good browser for Windows using WebKit2.

That's one way to frame it. Or you could use a plugin to request the h264 version, and keep the battery life gains of hardware acceleration on non vp9 accelerating devices (vp9 accel. is quite recent.) And still get to watch in 4k.

That's not how it works. If you request h264, there is no 4K option because there's no 4K h264 encoded version* .

Edit: As SG- pointed out, I also cannot read and Youtube is processing 4K h264, but not offering it on the main site. So it's puzzling why they're doing this. Bandwidth is a possibility, but you'd think it'd be consistently applied.

* You can test this using Chrome + h264ify. Which I use because the battery life when watching VP9 is truly horrific, and I don't care how much Google saves on bandwidth by pulling this stunt.

"The necessary support of the VP9 video codec for 4K playback today seems to currently apply to videos being watched directly on YouTube’s site. A quick way to check is to launch an uploaded 4K video on YouTube, and attempt to change the resolution. Recently uploaded videos only show HD options up to 1440p in Safari. Interestingly, if these very videos are embedded on an external page, then 4K video playback is still an option."

So it looks like they're encoding h264 in 4K, just not if you're on the actual Youtube site.

lets pray to formatting gods, :

D:\_learning>youtube-dl.exe -F https://www.youtube.com/watch?v=4Twcx4QozRc

[youtube] 4Twcx4QozRc: Downloading webpage

[youtube] 4Twcx4QozRc: Downloading video info webpage

[youtube] 4Twcx4QozRc: Extracting video information

[youtube] 4Twcx4QozRc: Downloading MPD manifest

[info] Available formats for 4Twcx4QozRc:

format code extension resolution note

249 webm audio only DASH audio 53k , opus @ 50k (48000Hz), 811.34KiB

250 webm audio only DASH audio 85k , opus @ 70k (48000Hz), 1.24MiB

140 m4a audio only DASH audio 95k , m4a_dash container, mp4a.40.2@128k (44100Hz), 1.47MiB

171 webm audio only DASH audio 104k , vorbis@128k (44100Hz), 1.44MiB

251 webm audio only DASH audio 127k , opus @160k (48000Hz), 1.86MiB

278 webm 256x144 DASH video 114k , webm container, vp9, 24fps, video only, 1.10MiB

160 mp4 256x144 DASH video 114k , avc1.4d400c, 24fps, video only, 1.67MiB

242 webm 426x240 DASH video 143k , vp9, 24fps, video only, 1.27MiB

243 webm 640x360 DASH video 248k , vp9, 24fps, video only, 2.22MiB

133 mp4 426x240 DASH video 260k , avc1.4d4015, 24fps, video only, 3.71MiB

134 mp4 640x360 DASH video 268k , avc1.4d401e, 24fps, video only, 3.23MiB

244 webm 854x480 DASH video 380k , vp9, 24fps, video only, 3.48MiB

135 mp4 854x480 DASH video 569k , avc1.4d401e, 24fps, video only, 6.62MiB

247 webm 1280x720 DASH video 761k , vp9, 24fps, video only, 6.77MiB

136 mp4 1280x720 DASH video 1101k , avc1.4d401f, 24fps, video only, 12.63MiB

248 webm 1920x1080 DASH video 1726k , vp9, 24fps, video only, 13.09MiB

137 mp4 1920x1080 DASH video 2324k , avc1.640028, 24fps, video only, 24.90MiB

271 webm 2560x1440 DASH video 4744k , vp9, 24fps, video only, 38.59MiB

264 mp4 2560x1440 DASH video 6415k , avc1.640032, 24fps, video only, 62.11MiB

266 mp4 3840x2160 DASH video 11632k , avc1.640033, 24fps, video only, 152.17MiB

313 webm 3840x2160 DASH video 16250k , vp9, 24fps, video only, 175.23MiB

17 3gp 176x144 small , mp4v.20.3, mp4a.40.2@ 24k

36 3gp 320x180 small , mp4v.20.3, mp4a.40.2

43 webm 640x360 medium , vp8.0, vorbis@128k

18 mp4 640x360 medium , avc1.42001E, mp4a.40.2@ 96k

22 mp4 1280x720 hd720 , avc1.64001F, mp4a.40.2@192k (best)

so 4K is indeed just hidden in the YT player, but present in the manifest

interesting that the file size for vp9/webm is usually smaller for all size options except for 4K where mp4/h264 seems smaller (at least for this specific video) meaning it's not really about trying to save bandwidth.

You are right and I am wrong. 1440p was max I was offered forcing flash player in opera and mp4 in chrome.

Out of curiosity, why was this article safari framed when it affects all browsers that want to use h264 4k including chrome and opera? Is there some way that this is actually a safari-centric change?

Because by default Chrome/Firefox/Edge support VP9 but Safari does not. By extension, if you aren't blocking VP9, and most people aren't, Chrome/Firefox/Edge get VP9 = 4K and Safari gets H264 = no 4K.

They are using it because they want to force Chrome and save bandwidth. What's puzzling you exactly?

In different eras and with different company, this would be called monopoly.

a) Why not do the same to embedded videos?

b) The only affected browser is Safari. Edge and Firefox remain unaffected.

c) How many people actually watch 4K videos, and how many videos are 4K?

So let's not go overboard on the conspiracy theories. For all we know, it could be a bug.

It's most likely not a bug, as YouTube and Google are known for forcing VP8/9/10/A1 down people's throats, because it's theirs and they want to "show it to Apple". For video sites, H.264 is the only option if they want to support Apple devices, and it's hardware decoding is widespread enough that it doesn't cause any issues. The only issue is it's patented and it's bad at encoding compared to VP9/H.265. But we can just switch to H.265 anyways, and given that Google deprecates their codecs every 2 years, I don't think that they will ever have good hardware decoding support.

> The only issue is it's patented and it's bad at encoding compared to VP9/H.265

Your argument is that Google is evil for pushing a codec that's patent-free and better as a codec? Also, as others have stated, VP9 has wide hardware acceleration support (and will have wider support in the future)?

> I don't think that they will ever have good hardware decoding support.

Almost all modern the GPUs and processors have hardware decoding for VP9

VP9 version file has higher bitrate and is bigger.

Good catch. Is that always the case, or just for the example you analysed?

Thats the case most of the time I bothered looking. It seems Google is trying to make VP9 versions look better, and despite all the hype around their codec the only way to achieve that is thru bigger bitrates :/

Reply on news.ycombinator.com