Note that the encoders are slower largely because it's not hardware-accelerated yet.
We can reasonably assume that will change, as basically every major player in the CPU/GPU spaces[1] has signed on to back this. Even Apple is a member.
[1] the exceptions are mostly downstream ARM vendors - notably, Qualcomm
You've linked competing hardware encoding APIs which are not x264/x265.
x264/x265 are software encoding libraries for H264/H.265 video formats and don't really use hardware acceleration beyond SIMD instructions on CPUs. x264 is known for its great output quality while still being fast on x86 CPUs.
x264 and x265 refer to the specific set of software programs of the same name, right? Most chips nowadays can hardware accel H.264 and H.265, but they don't use x264/x265 (or do they? Not sure...). I think the confusion is that the terms x264 and H.264 are not interchangeable
> Qualcomm being closed source is the biggest issue with running good (user-respecting) software on phones, since basically every single Android has a Qualcomm processor/GPU.
Actually there are kernel drivers for several Snapdragon platforms now, to the point that a Poco F1 can boot both GNU and AOSP-based systems off mainline.
I, for one, have a bigger problem with it forcing the use of phone numbers as a sign-in method. They're an arbitrary identifier from a legacy system that there's not really a point in continuing to extend, because if your device is capable of anything more advanced than SMS it's also capable of... well, this.
Also KaiOS and the like are making chat feasible even on feature phones.
Don't get me wrong, RCS will be a fine enough fallback (once it's E2E), but standardized chat is the dream.
> Don't get me wrong, RCS will be a fine enough fallback (once it's E2E), but standardized chat is the dream.
Is there a plan for RCS to be E2E? Given that RCS went under the GSMA umbrella in 2008, and it's 2020 and adoption is minimal, I don't have any hopes for a future update that supports E2E to come out any time sooner than 2040, with handsets supporting it in 2050, and all endpoints supporting it in 2065; Google will have released about 30 more messangers by then, of course.
Tackling this point separately: the entire reason they do this is because they routinely experiment with side projects and then build the ideas that work well into the services that gain traction. As much as it comes with the drawback of being scattershot in general, it specifically creates a track record for failure with messaging because successful messaging products, as a rule, have network effect - something you can't build when you're playing with three different approaches simultaneously.
For an example of where this works really well, look at how all of their adaptive UI efforts feed into each other:
* The enhancements to multiwindow that were built for foldables became Android's desktop mode, to the point that it was built specifically as a test environment and now underpins DeX etc
* Desktop mode's only hardware requirement is a display output, suggesting in addition that Android apps as a whole are no longer bound to specific 1:1 relationships of UI and form factor. (This is, imo, a much bigger deal than we're making it out to be, and opens up possibilities ranging from hybrid game consoles to mobile content creation to better takes at mobile-powered VR.)
* The existence of a base OS implementation and the fact that it's controlled by the system launcher, a component the user can rip and replace, pretty much ensures that custom ROM communities are already toying with this
* Android supports PWAs - installable, natively-scalable webapps - meaning that when desktop mode inevitably stops being feature-flagged there will be examples of convergent apps that work on day 1
* Desktop support for Android apps enhances those same apps when used on ChromeOS
* Flutter, the toolkit built for Fuchsia - an OS designed from the ground up with this sort of scalability in mind - is capable of targeting all of the above
>As much as it comes with the drawback of being scattershot in general, it specifically creates a track record for failure with messaging because successful messaging products, as a rule, have network effect - something you can't build when you're playing with three different approaches simultaneously.
I think what Google needs to do is to seperate the messaging protocol from the messaging software. The protocol needs network effects. The software doesn't. That's why shutting down Google Inbox didn't kill email and it's why any new experiments with email software can benefit from the network effects that email protocols already have.
Hard agree. I'd also argue that any meaningful antitrust action we may eventually impose on big tech companies should force this.
If the one thing so far that's led the feds to threaten this is that they wanted to build a modern protocol for cross-service messaging, then there's no sane reason we couldn't have asked for that exact thing as a spec.
Not within the spec. Which was sort of the point I was (poorly) trying to make - that it's a huge caveat, but otherwise a decent fallback if and when that changes.
Google is adding an implementation into Messages, and it's honestly not a critical problem if OS vendors are supporting it at that level, but there's still too much we don't know about it imo. Will that be supported by iOS, if and when it supports RCS at all? Will it work for third-party clients, if and when Android gets APIs?
I'm not sure how much optimism I have that this will be anything other than a fragmented mess in the short term.
The only thing getting RCS any real traction is Google seems to be pushing it in their SMS application, and is now running an RCS server for everyone (or something).
Which basically means, instead of having a federated mess as designed to replace the federated mess of SMS and MMS, we'll get a Google mess, maybe. But if Google was any good at making messenger apps, maybe enough people would use one of them that it wouldn't be killed.
Which just sort of loops back to how if Web-based chat had a spec with meaningful user traction we wouldn't have any real use for RCS in the first place.
Also how XMPP could have been that spec, if Google hadn't decided when launching (the first version of) Hangouts to go full Ayn Rand while doing it.
"even on feature phones"? It was perfectly possible at least back in the early 2000's. Where I'm from, we've gone through a lot of different IMs over the years, including XMPP (which I was a big fan of, but started to despise because it had such terrible support for mobile clients). Many J2ME clients had pretty advanced features like group chats and file transfers.
Also worth noting that one of Google's long-term goals is to make Android bootable on mainline. They've been slowly upstreaming the patches they built into Android's base kernel, and their Treble roadmap involves further isolating the hardware drivers, to enable running a generic kernel across devices.
Yes and AIUI, libhybris is working on supporting those userspace hardware drivers on a non-AOSP install. The postmarketOS folks would rather do without using downstream code/drivers/firmware at all and keep everything upstream based, but some devices will need this and it might also be useful for quick bring up on new devices.
Or that you still call your OS "intuitive" after shuffling keyboard shortcuts around so hard that not only is your OS running a completely different set of hotkeys from everything else you use, but so is every app you used that will run on it.
Or after making it a three-key shortcut to take a fucking screenshot.
Tl;dr up front: For now. The UI absolutely isn't as fleshed out, but that's not the thing that makes this important.
Yeah, it's built primarily as a test environment for apps that require free-form multiwindow, multi-resume, and the like -- think foldables, mostly. So it's pretty skeletal at the moment. (Incidentally it's also hidden behind a developer flag.)
However, it's managed by the system launcher, meaning it can be extended by the community or by OEMs, and the Android team is actively encouraging people to do that. It also means that there's a set of standard interfaces for them to build this functionality on. The latest version of DeX was reworked to use it, LG rolled out an implementation with Android 10, and there have been rumors of Nvidia working on a transformable SHIELD device. (I would assume EMUI Desktop was also rebased, but haven't seen anything confirming that.) It's also starting to pop up in custom ROMs like BlissOS.
This has much bigger implications than DeX did (or foldables do), imo, for a few reasons:
- Google has been slowly building out broader, less hardware-dependent support for large form factors across a variety of projects - from ChromeOS' Android runtime (which will also benefit from more developers targeting this), to Fuchsia's scalable UI, to Flutter's recent web and desktop support, to PWAs (which are responsive by definition) and their integration into pretty much every major platform. The ecosystem around convergence across their products is actually a bunch of different pieces that are all evolving somewhat in parallel, all of which are somewhat symbiotic with one another, and many of which you can try out in some form right now.
- That said, this particular piece has a much lower barrier to entry. You don’t need a particular class of Android device or laptop, or a specific product, or a custom ROM, or even root. That doesn’t mean the average user will pick this up for a while, but the fact that the average user can guarantees that a bunch of tinkerers and power users already are. Something which never happened at scale for, say, Android tablets.
- This creates a lot more incentive to build for desktops, with the potential to then recycle that larger UI for form factors like tablets. Giving desktop UIs a standard base means that supporting, say, DeX no longer has to mean writing a vendor-specific implementation (see also: biometric sensors, styli, and various other hardware classes that the ecosystem has picked up over time, but only got broad third-party support after being added to AOSP), and the fact that it only requires a display output on your device enables you to target a much broader audience (even if your current audience is mostly just places like XDA).
Putting aside broader conversations about the kinds of use cases that could arise from convergent UIs, I’d argue that this is one of the biggest steps forward we’ve had in a while toward making that future actually happen.
11 is still early into its public testing phase -- developer previews are essentially pre-beta -- so it's hard to really make concrete guesses at what user-facing stuff will show up in the next version at this point.
Depends on your device state. If you've unlocked your bootloader already, you should only need to wipe system-level partitions (which would affect applications, but not user storage).
But if you haven't, you need to do that first, which requires you to wipe your entire device, including data.
