YouTube no longer supports 4K video playback in Safari(9to5mac.com)

67 pointsby clouddrovervor 10 Jahren74 comments

YouTube no longer supports 4K video playback in Safari

https://9to5mac.com/2017/01/12/youtube%E2%80%A4com-no-longer-supports-4k-video-playback-in-safari/

81 comments

Asking here because this might have some visibility:

What's the status of hardware acceleration of next-generation video standards (h.265, VP9, something else)?

It's my understanding that after VP8 was pushed and then superseded rapidly, hardware manufacturers are now leery of implementing anything other than h.264.

And as a follow-on: what makes generic GPU hardware and software not sufficient for hardware acceleration of video decoding? What is it that makes my GPU stupendously good at pushing pixels and training neural nets and physics calculations and so many other things, but not better than my CPU at video decoding? Is there a reason h.265 and such aren't implemented in CUDA?

I don't know much about video encoding, not even enough to be dangerous, so to speak.

MyOwnSpiritvor 10 Jahren

hevc (h.265) has specialized hardware which encodes or decodes much faster than other GPU solutions. I believe typical graphic cards come with hardware codecs within them but I am not sure. Regarding why hevc isn't so easy to use with GPU, it comes from the way video compression is done. In video compression, you don't really process each pixel one by one independently. Instead, you consider blocks of pixels and you look for similar ones in other pictures. So it is not much about having many similar small tasks but really one big one. Besides, to minimize the information to send (i.e. to compress better), the compression of each block is based on what the left and top blocks have done. If I compress all my blocks in parallel, I will not be able to make them use each other's information. Does this help you see the big picture?

dogma1138vor 10 Jahren

CUDA supports VP9 decoding since Kepler iirc.

jsheardvor 10 Jahren

VP9 was added in VDPAU Feature Set F, which was introduced with the later Maxwell chips (950/960 cards have it but 970/980/980ti cards don't).

dogma1138vor 10 Jahren

VP9 decoding was supported since Feature Set E, it was running a combination of a native ASIC decoder and a set of shaders running on the GPU. So while it wasn't as power efficient as the dedicated PureVideo hardware block it was still GPU accelerated.

jsheardvor 10 Jahren

I'm curious, do you have a source for that? I know that Feature Set E cards used a hybrid ASIC/GPU approach for H.265 but I can't find a mention of hybrid VP9.

dogma1138vor 10 Jahren

It's done via DXVA (2.0) if you query DX on a Maxwell card (or even Kepler) you should get something like VP9_VLD_Profile0: DXVA2/D3D11, SD / HD / FHD / 4K (You can either manually do it, or there is a tool called DXVA checker or tester or something along those lines).

LAV Filters (an Open Source implementation of DirectShow/DXVA filters) VP9 support works with Maxwell cards for sure, I have a 780ti somewhere I can check Kepler also, but IIRC it should work.

That said this would work for many video players that use DXVA or have support for external DS filters e.g. VLC/MPC-HC or proprietary players like Splash, but it won't work in a browser. Chrome for example doesn't allow for external filters iirc so you'll see a pretty big CPU jump. For some reason it seems fine on VP9 1080p videos on a Maxwell card CPU is 2-3% but at 4K it jumps to 70-80% I have a feeling that since Maxwell has partial support in the PV block for HEVC and VP9 they might be able to decode 1080p with it and then do full CPU decoding for 4K, I wouldn't expect CPU decoding for 1080p to be so resource efficient otherwise.

dogma1138vor 10 Jahren

Just some more info this is the DXVA GPU accelerated decoder http://imgur.com/a/9MPsp http://imgur.com/a/q8SfN It basically decodes a VP9 stream with a shader and outputs it into an image format inluding NV12 which means you can use PureVideo for direct ouput.

This one can work with either a dedicated media player or with Edge, Chrome does it's own thing and I'm not entirely sure what they do and I have no clue about Safari/Opera/Firefox so if some one wants to fill in about them that would be nifty.

Whilst technically DXVA is a software decoder https://en.wikipedia.org/wiki/DirectX_Video_Acceleration It does offload the heavy lifting to the GPU via shaders, so can still some what classify it as "hardware decoding" since softare decoder/encoders are usually defined as CPU only.

Veratyrvor 10 Jahren

Not so much CUDA as NVDEC. And VP9 support was introduced in Maxwell Gen 2: http://developer.download.nvidia.com/designworks/video-codec...

dogma1138vor 10 Jahren

Yeah I meant to write NVIDIA not CUDA, FYI you need to login to download stuff from NVIDIA, try copying the URL with the auth parameter ;)

I've made a post about how VP9 is offloaded to GPU in this thread, it's done via DXVA/MF on Windows.

Veratyrvor 10 Jahren

One of the APIs is DXVA/MF on Windows but the underlying hardware is still NVDEC (and you can use the NVDEC API directly if you so choose). It and NVENC are specialised hardware modules.

[deleted]vor 10 Jahren

kttavor 10 Jahren

>What's the status of hardware acceleration of next-generation video standards (h.265, VP9, something else)?

You're only likely to find proper hardware acceleration for the top codecs like h.264, not much else. There's going to be software acceleration for everything else. So from the MPEG[2] group, as you might expect, there's h.265. But then there's a whole new undertaking by the big guys like Netflix, Google, etc. which is called AOMedia[1]. Now they have this new codec called AV1[3] which is still in development. And it's open source and royalty free which is not usually what happens in the MPEG group because they charge royalties and have patents on the codecs/standards they have.

>what makes generic GPU hardware and software not sufficient for hardware acceleration of video decoding?

Now I'm not a video encoding/decoding expert, but just enough to be dangerous actually. What makes GPUs well suited is that they have many, many more cores so each core can handle a specific area of the video output that needs to be decoded.

It's called parallel programming. Whatever can efficiently be implemented on GPUs better than CPUs, people are doing it. This is recently being called GPGPU programming, where tasks that were thought were better done by CPU are being re-programmed for the GPU since the development and performance in GPUs have been going through the roof.

Now when it comes to the why, think of it this way. Your average complex computation is more like lifting a couple really heavy boulders. So you need a strong person to lift it. So that strong person is your CPU core, with complexity and high clock rate. But video encoding is not that complex at the pixel level. So it is more like picking lots (thousands) of tennis balls. GPUs are like having a bunch of kids (current gen GPUs have ~2000 cores even at the mid-range) who are no where as strong as the strong CPU guy, but you can guess who will get the task done faster.

[1]:http://aomedia.org/about-us/

[2]:https://en.wikipedia.org/wiki/Moving_Picture_Experts_Group

[3]:https://en.wikipedia.org/wiki/AOMedia_Video_1

clouddrovervor 10 Jahren

> You're only likely to find proper hardware acceleration for the top codecs like h.264, not much else.

Intel, Nvidia, AMD, and ARM all support VP9 acceleration:

https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

http://www.tomshardware.com/reviews/intel-7th-gen-core-kaby-...

https://en.wikipedia.org/wiki/Nvidia_PureVideo

https://en.wikipedia.org/wiki/Unified_Video_Decoder

http://www.anandtech.com/show/10428/arm-announces-mali-egil-...

https://en.wikipedia.org/wiki/VP9#Hardware_encoding.2Fdecodi...

TheAceOfHeartsvor 10 Jahren

Personally, I've stopped watching video directly on YouTube.

Instead, I installed mpv [0], and since it embeds youtube-dl [1] you can play any video with the native UI by running:

    mpv "youtube_url"

[0] https://mpv.io/

[1] https://rg3.github.io/youtube-dl/

neotekvor 10 Jahren

mpv is fantastic. I recently decided to abandon MPlayerX when I found out about their incredibly dishonest malware bundling tactics[1] but was surprised at how few good media players there are for macOS, until I read about mpv.

mpv took a little bit of getting used to since it doesn't offer a lot of useful stuff out of the box (automatically queuing files, subtitle downloads, etc) but since you can write quite powerful scripts for it that didn't remain a problem for long.

[1] https://blog.malwarebytes.com/puppum/2016/09/pup-friday-mpla...

TheAceOfHeartsvor 10 Jahren

If you're on macOS and looking for something with a nice GUI, check out IINA [0]. I saw it on HN [1] last week, and it looks very promising, although it's still an alpha. It's based on mpv.

[0] https://lhc70000.github.io/iina/

[1] https://news.ycombinator.com/item?id=13337444

LeoNatan25vor 10 Jahren

Iina is very promising. Keep in mind that it is still very early in development, but I really like the mindset of the developer and contributors - creating a macOS experience, not cross-platform that looks bad everywhere.

MPlayerX was once upon a time also that, but its maintenance went vaporware a few years back, and the bundled crap finally killed it. So for a while now, I've been looking for a good player. Seems Iina is that player.

[deleted]vor 10 Jahren

qqiivor 10 Jahren

What is your process for browsing for content then, do you still browse the YouTube website?

rasz_plvor 10 Jahren

small tempermonkey script replacing all YT embeds with custom URI + custom URI handler calling mpv "youtube_url" (or in my case extracting direct 720p stream https://xxxx.googlevideo.com/videoplayback... link and passing it to SMPlayer)

This lets you watch every single YT clip using player of your choosing. Result is smooth video on 10 year old laptops(1.8GHz Core2) when Flash/browser buildin codecs are barely able to play 480p.

vinay427vor 10 Jahren

Would you consider publishing the script somewhere? I can't speak for others, but I would personally be inclined to use it as I'm looking for a YouTube client alternative.

rasz_plvor 10 Jahren

https://github.com/raszpl/smplayer4YT

its a mess, but ~works :)

[deleted]vor 10 Jahren

TheAceOfHeartsvor 10 Jahren

Yeah, I don't usually watch that many YouTube videos. In addition, I only follow a handful of content creators, and they don't post that frequently, e.g. Primitive Technology.

ufovor 10 Jahren

What is your opinion on mpv vs vlc?

kyrravor 10 Jahren

Not that it matters to everyone, but YouTube limits users of YouTube-dl to 720p resolution I believe. If you want 1080p or higher you have to do in-browser.

groksvor 10 Jahren

    $ youtube-dl --list-formats https://www.youtube.com/watch?v=DeJLzyxZqbk | grep '[0-9]x[0-9]'
    278          webm       256x144    DASH video   93k , webm container, vp9, 24fps, video only, 1.09MiB
    242          webm       426x240    DASH video  110k , vp9, 24fps, video only, 1.00MiB
    160          mp4        256x144    DASH video  113k , avc1.4d400c, 24fps, video only, 1.41MiB
    243          webm       640x360    DASH video  196k , vp9, 24fps, video only, 1.83MiB
    133          mp4        426x240    DASH video  247k , avc1.4d4015, 24fps, video only, 3.08MiB
    134          mp4        640x360    DASH video  263k , avc1.4d401e, 24fps, video only, 2.95MiB
    244          webm       854x480    DASH video  322k , vp9, 24fps, video only, 3.11MiB
    135          mp4        854x480    DASH video  554k , avc1.4d401e, 24fps, video only, 6.30MiB
    247          webm       1280x720   DASH video  714k , vp9, 24fps, video only, 7.48MiB
    136          mp4        1280x720   DASH video 1127k , avc1.4d401f, 24fps, video only, 12.92MiB
    248          webm       1920x1080  DASH video 1579k , vp9, 24fps, video only, 17.86MiB
    137          mp4        1920x1080  DASH video 2304k , avc1.640028, 24fps, video only, 27.09MiB
    17           3gp        176x144    small , mp4v.20.3,  mp4a.40.2@ 24k
    36           3gp        320x180    small , mp4v.20.3,  mp4a.40.2
    18           mp4        640x360    medium , avc1.42001E,  mp4a.40.2@ 96k
    43           webm       640x360    medium , vp8.0,  vorbis@128k
    22           mp4        1280x720   hd720 , avc1.64001F,  mp4a.40.2@192k (best)

dindrestovor 10 Jahren

Nope, youtube-dl is able to grab the DASH sources, which includes 4k, 1440p and 1080p. :) The DASH video and audio sources can then be muxed by mpv on playback.

[deleted]vor 10 Jahren

std_throwawayvor 10 Jahren

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

BoorishBearsvor 10 Jahren

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?

greggmanvor 10 Jahren

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

LeoNatan25vor 10 Jahren

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

greggmanvor 10 Jahren

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).

kitsunesobavor 10 Jahren

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.

LeoNatan25vor 10 Jahren

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.

kitsunesobavor 10 Jahren

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.

LeoNatan25vor 10 Jahren

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.

RichardHeartvor 10 Jahren

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.

guitarbillvor 10 Jahren

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.

SG-vor 10 Jahren

"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.

rasz_plvor 10 Jahren

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

SG-vor 10 Jahren

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.

RichardHeartvor 10 Jahren

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?

guitarbillvor 10 Jahren

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.

[deleted]vor 10 Jahren

LeoNatan25vor 10 Jahren

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.

rasz_plvor 10 Jahren

VP9 version file has higher bitrate and is bigger.

guitarbillvor 10 Jahren

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

rasz_plvor 10 Jahren

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 :/

guitarbillvor 10 Jahren

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.

milankragujevicvor 10 Jahren

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.

Godel_unicodevor 10 Jahren

> 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)?

Oletrosvor 10 Jahren

> 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

nrjdhsbsidvor 10 Jahren

Good. Screw MPEG LA for hampering the development of AV codecs and making free software using audio/video a pain in the ass for a decade.

kartickvvor 10 Jahren

As someone who has to live with a 4mpbs connection, if VP9 produces better quality video, I'd want Apple to use it.

I use an iMac, so battery life is not a concern. Even otherwise, I'd take video quality over battery life.

celsoazevedovor 10 Jahren

Maybe it has something to do with costs? VP8 and VP9 are free while distributing h.264 and h.265 content will cost millions in fees per year. It makes sense to use free codecs instead of h.26x

WildUtahvor 10 Jahren

Alphabet's Google's Youtube already pays the maximum annual license fees to MPEG-LA. They're not concerned about saving money by switching.

MyOwnSpiritvor 10 Jahren

Also people maybe should realize that vp8 and vp9 are not entirely based on free patents. Instead, Google pays companies to use their patents and distribute the related technologies freely.

kuschkuvor 10 Jahren

> VP8 and VP9 are free

Unless Google ever uses one of your patents, and you have to sue Google over that.

VP8 and VP9 come with a no-litigation clause that basically requires you to share all your patents with Google if you use VP8 and VP9 – which is a shame.

lern_too_spelvor 10 Jahren

No. Here's the license. https://www.webmproject.org/license/additional/

You only lose the right to use WebM parents if you file litigation against any user of WebM (not just Google) over any implementation of WebM. You can sue Google about anything else and not suffer WebM license consequences.

You're probably thinking of Facebook's open source patent rider. https://github.com/facebook/react/blob/master/PATENTS

kuschkuvor 10 Jahren

Indeed, turns out, I was wrong on that. Now I wonder, if i own MPEG patents, could I sue Google for misuse of them, while licensing WebM? There’s quite some overlap with them.

And yes, Facebook and Tesla’s patent licenses are completely ridiculous.

lern_too_spelvor 10 Jahren

You can sue Google about misuse of MPEG patents and keep your protections under the WebM license, so long as you do not sue Google or anybody else about WebM's patents.

clouddrovervor 10 Jahren

> basically requires you to share all your patents with Google if you use VP8 and VP9

Do you have a link to the license which says you must share all your patents with Google?

kuschkuvor 10 Jahren

It turns out Google removed the "you lose the right to the license if you sue Google for literally anything" part, but Facebook still has it in React, and Tesla has it in their licenses.

That’s the usual wording of these clauses, and the problem.

shmerlvor 10 Jahren

Good. No one stops Apple from supporting free codecs. Google should have done something of the sort a long time ago. But they didn't, and proliferated H.264 usage.

akjainajvor 10 Jahren

VP9 uses a retarded amount of CPU compared to h264, so I can't blame Apple for not wanting to implement it.

phkahlervor 10 Jahren

>> VP9 uses a retarded amount of CPU compared to h264, so I can't blame Apple for not wanting to implement it.

h264 uses a retarded amount of bandwidth compared to VP9, so I can't blame Google for not wanting to implement it.

Google is still providing a choice here, except for 4K where it costs them twice as much. Apple on the other hand has no excuse for not implementing both. There is also a free low-power hardware implementation of VP9 which Apple (who makes their own SoC) could choose to use but hasn't.

ebbvvor 10 Jahren

> which Apple (who makes their own SoC) could choose to use but hasn't.

They don't make their own SoC for their laptop and desktop machines, which is who this primarily affects. 4K on iPhones doesn't matter since they only have 2560x1440 resolution.

Oletrosvor 10 Jahren

They can use Intel built-in hardware decoding

LeoNatan25vor 10 Jahren

iPhone 7 Plus, the latest and largest phone, has a 1080x1920 display.

ebbvvor 10 Jahren

Yeah you're right I got it mixed up which of my displays my phone had the same resolution as. :P

[deleted]vor 10 Jahren

Oletrosvor 10 Jahren

Slylake and Kaby Lake have hardware decoding of VP9

lern_too_spelvor 10 Jahren

Indeed, Google not doing something sooner is what caused Firefox to accept a proprietary h264 blob, leading to the eventual acceptance of h264 as a required codec in the WebRTC standard.

callesggvor 10 Jahren

What a waste of battery power.

Most modern computers have hardware ASIC's capable of decoding h.264. It is a total waste to not use it.

johnnydoe9vor 10 Jahren

For most people net speeds is a bigger problem than battery drain.

callesggvor 10 Jahren

I see your point. In this specific circumstance it would probably not be an issue.

As one could say that 4K video and network speed issues don't go hand in hand.

drivingmenutsvor 10 Jahren

No big loss for me, no matter how you slice it. I don't watch that much video on YouTube and I prefer to d/l it with youtube-dl if I'm going to be involved with it longer than 5 minutes.

Girlangvor 10 Jahren