Orphis

Don't forget, they built the platform, but 3rd party apps are what gives it value. Very few people would use an Apple device if they didn't have access to their games or productivity apps.

Moreover, users pay a high premium for their device to access the platform. Why should companies also pay in addition to the annual subscription fee to their developer program?

Spotify doesn't own any distribution. The labels do, and they could just not renew their contract and move to a competitor's service at a whim, destroying the company (who wants a service where 1/3 of the artists are not available?).

They have the biggest share currently, but they're never safe.

I worked on Jpcsp a long time ago, PSP emulator in Java. It was the first emulator to manage to run a large amount of games. We had some crazy devs on it who even wrote a MIPS to Java bytecode JIT. It worked great... sometimes. We ended up running into lots of JIT issues as some patterns were unusual and not always properly handled by hotspot. Fun times!

To me, the solution is simple: use a single source (some IDL format) to define objects at API boundaries and have your frontend and backend use it.

It will make it a lot harder to return wrong types from your calls. Personally, I like gRPC + Protobuf.

The Chrome stack has been highly tuned to make a Stadia use case work, but Firefox hasn't, making highly latency sensitive usage difficult for now.

Technically, it's SRTP with keys derived from the handshake of a DTLS connection though. That DTLS connection can be used for SCTP, the underlying protocol for WebRTC data channels.

So yeah, that won't work to stream to a WebRTC endpoint as you said!

And then it fails because you don't have "make" or a compiler installed. Build dependencies aren't an issue as long as they are reasonably standard and easy to install.

STUN is basically a way to know your external IP address to share to others and have both peers try to connect to one another through them. It's lightweight.

If that fails, then there's TURN which acts like a proxy between the peers.

It could be the TURN server adding latency or some issues browser side.

Which browser and version did you use?

Yet, you cannot have a link to Netflix or Spotify from their app to their own website as you could subscribe on it.

And the browser is limited to whatever Apple allows. If it doesn't support some web API that has a native equivalent, you're out of luck. There are many of those.

Spotify can also chose to prevent older clients to connect and only allow the latest one with new protections rendering this attack useless.

Some work needs to happen locally to show you a preview of what you're going to transmit, as it should for most video related work.

If the segmentation is done server-side, then you need to sync it to the sender and reflect that quickly in the preview. It's probably not a great experience, at least for a launch.

For push to talk to work, you need to have access to keys even when you're not in focus.

That's not something doable today on the web for obvious security reasons, but it's possible for Discord that has a separate app, would be doable for Zoom too I guess.

They're quite easy to skip on most content. Some even put a "loading bar" to easily identify when it's going to end.

Why don't you have a personal browser profile where you are logged in YT to watch any video?

Everyone trying to put the blame on their government response will say that Sweden is a success.

Everyone in Sweden disliking the government response or supporting their own government response will say that Sweden's approach has failed.

A long time ago, I bought Half-Life 1 in a regular store. I tried to play with a friend online but it said my CD-key was already being used. Turned out my friend had bought the game, came without a CD-key printed on the box, so the store opened a random box and gave him that CD-key. I bought that exact same box.

In the end, my friend sent a picture of the box to Valve and got a fresh CD-key, and we could finally play together.

You also have games and "remote control" apps that use WebRTC (controlling a computer or a robot).

It's really not great. Doable, but not great. That's why they moved to a classic C++ codebase instead on other platforms.

On a side note, I worked on Jpcsp, a PSP emulator in Java. Great for research and doing refactoring in the code quickly, not great for performance, even with a JIT. We wrote later PPSSPP in C++, performance was there quite easily.

A lot of banks unfortunately.

If you cache only at the file level, then you're going to miss a lot of opportunities and still repeat a lot of work.

You could cache at the function level, or each template separately. You could cache includes automatically on files that change frequently to avoid parsing headers again and again without having to manually specify precompiler headers (yes, sure, modules should help there soon).

If you don't read the documentation, sure, it's hard to guess how things work, but it's hardly the responsibility of the tool maker to change that.

If people try to reimplement things in arbitrary broken shells scripts (the user issues) that can't be run locally, then it's not the CI tool's responsibility either.

I like the TeamCity UI. There I said it and mean it.

Sure, TC has had issues (especially when it came to scaling), but they fixed a lot of those and honestly, it's doing well now.

Issues usually came from people who didn't know how to make robust pipelines or leverage TC's functionality and felt like they had to reinvent everything. And that was in a company with thousands of employees, thousands of TC configurations and hundreds of agents.

They do apply to all codecs, absolutely. Some just have historically more usage, so the encoders might behave better. There are still bugs though, I do remember hearing about some device producing an H264 stream that another device couldn't decode in HW. It's still not perfect.

Also, as many people have pointed out, VP8 is a more complex codec than H264, so harder to test coverage of all features, especially as most applications (especially on desktop) are not really doing RTC, which is quite a specific use case.

And phones DO have VP8 encoders. It's just that iPhones for historical reason don't have one. Pure speculation from my part, but I'm guessing they'll do AV1 someday as Apple is working on the spec.

But in general, even though HW encoders would be awesome for all codecs if they were working well in all situations, the reality is they don't always work, you usually need to build lists of HW that is supposedly behaving well with your use case. All advanced features (eg spatial layering) are tricky to implement in HW and are usually not configurable, so SW codecs will still have quite a lot of usage for the sake of quality.

There are WebRTC SDKs for Android and iOS.

> WebRTC the sender degrades quality to satisfy the slowest peer

No, WebRTC is 1 to 1. Each connection is adapted independently. But, you can build services that have rooms with more participants, then it's up to you to shape the traffic as you want. If you use a central server (SFU), it can just send each peer the best they can receive, each independently from one another. It's a property of the service, not the technology.

It's not just about NAT but firewalls too. I have native IPv6 but you can't reach my computer directly from anywhere.

If you can't do P2P, you can have an SFU forwarding the call with more features than a "dumb" TURN relay.

And it would just be STUN between each participant and the SFU deployed in the internal network for example.

There are HW VP8 encoders around. Can't find a definitive list, but I suspect most of the ones that can do VP9 will do VP8 as well: https://en.wikipedia.org/wiki/VP9#Hardware_implementations

Disclaimer: I work on WebRTC somewhere in the codec stack. Certainly not the most knowledgeable in that field but here are a few reasons.

Software encoders will always have more features than hardware encoders, which are prone to bugs.

A bug in a HW encoder needs either a new driver or new silicone. You can't work with those and sometimes you can't even detect which version it is.

So if you want to ship a reliable application, you can either use a software codec (which you control) or hope the HW encoder which is totally random works as intended.

HW encoder bugs show in many forms. Sometimes the stream is just broken and can't be decoded, sometimes it won't listen to encoding parameter updates you send it (eg max bitrate or quality settings), sometimes it just generates a valid but bad stream (too many I frames, breaking the max bitrate setting), sometimes they have a TERRIBLE latency.

Sometimes, they just plainly lack features, for example can't encode temporal layers, don't have any denoising (useful for VP8), have a limited amount of instances limiting simulcast opportunities, have extreme frame size limitations (can't do screensharing with it)...

And that's just what I could come up with in a few minutes of thinking, I'm sure people who have worked on it for a much longer time would be able to say much more.