Unless they have hardware encoder and decoder design done in parallel, otherwise it would be 2028 before a hardware block design is done and 2030 for the earliest product to ship with it. In reality I think 2031 or 2032 is more likely.
And I have been saying the same for quite some time that 20-30% for a generational codec improvement isn't worth it. I think they originally aimed at 50%, and then 40% and then 30%.
Firefox is getting the flag to turn it on in the next release, chromium just added it back now there is a rust decoder. The wheels are turning again. Browser support for jpeg xl is very much in progress again.
Have you said this for Audio Codec I would have agreed. I do not know a single Smartphone Video Conferencing software that uses CPU encoding rather than hardware encoding. Neither WhatsApp or FaceTime, perhaps the largest of the two real time Video Call uses AV1.
Google Meet can do it. You don't want the full conference with AV1, just use it for very low bitrate scenarios with a high packet loss possibly. Phones are a good target system. And I know this is quite opposite to expectations.
It is a lot better to send a stable and visually ok stream with AV1 at 30KBps than fail to send a VP8 50KBps stream that is unusable anyway and is subject to twice as many packet lost than a lower bitrate solution.
It is possible they use AV1 in other scenarios now, but I left the team a while back now and I haven't checked what they are now using under the hood.
Yeah, no production or large scale VC system is running software AV1 encoders on smartphones. You will drain a full phone battery in 1-2 hours of calls.
It just doesn’t make sense and will result in extraordinary power/battery drainage at best, or output that’s worse than hardware encoding.
The only way you could get AV1 to software encode in realtime AND low latency on a mid-range Android chip is by disabling or skipping nearly all of the compression/encoding features that make it good at low bitrate.
> Yeah, no production or large scale VC system is running software AV1 encoders on smartphones. You will drain a full phone battery in 1-2 hours of calls.
Yeah but, half jokingly, Zoom does that (draining the battery in an hour) already :P
The website, and backend code for the test. 10% of the software work. Which is what everyone seems to think.
The code to managing the infrastructure, network connectivity, load balancing, and capacity planning is the 90% of the software part. But even then it is only 10% of the technical thing.
Getting all the ISP onboard to have your server in their network / exchange and to deal with you, takes more time and effort then all the software part. But even then it is only 10% of the project.
The remaining 90%? Non technical part for Sales and Marketing and getting user traction.
To put that into perspective, the website can be done in a weekend was only 0.01% of the work.
Such heresy is detrimental to EU sovereignty... next you're going to remind people that some states are in the EU despite their citizens having opposed going in there.
TBH, EU member states can be plenty oppressive when they want to, so - why not just take it to the next level and have all-European overlords?
There's literally an entire section in the Treaty of the EU on the exact criteria to leave the EU. A country has literally _left_ the EU. Nobody is being held hostage to stay in the EU.
"Despite their citizens having opposed going in there." Can you point to a vote to invoke Article 50 that was not honored by the EU? Can you point to a country getting admission into the EU without a vote from their people?
That's a rather odd point. One country has left the EU due to a very narrow 'exit' vote, so it's not anyone's prison. Across surveys the EU enjoys broad support, often even more so than the national government.
Clearly not everyone loves the EU but the majorities are very much in favour (and certainly this is the case among the people who actually understand politics, economics, etc.).
I think the grandparent references many referendums that rejected EU treaties:
- Maastricht Treaty, 1992, Denmark,
- European Constitution, 2005, France and Netherlands,
- Lisbon Treaty, 2008, Ireland.
The votes were usually redone and passed. The exception is Norway which refused to join twice.
> Clearly not everyone loves the EU but the majorities are very much in favour (and certainly this is the case among the people who actually understand politics, economics, etc.).
This is quite the loaded statement. I've heard from people on either both sides of the argument that understood politics and economics very well (professors, lecturers, etc.)
It's always interesting to see accounts popping up in this thread trying to delegitimize EU and spew out bunch of vague misleading statements against it.
Why is that? Which EU citizen protection is angering you? :)
Nothing of that is angering me, I live in the EU and life is pretty nice.
My comment above was meant to provide context and to point out that both sides of the argument can be legitimate.
The comment is neutral, you shouldn't be able to infer what I think about the EU from it. It simply points out facts and says that reducing a point of view to being uninformed is too easy.
My stance on the EU is complex: it does good, it does bad, it affects each member states differently, it changes over time. Those are all pretty neutral statements too, only siths live in extremes ;-).
Are we really bringing back this debate from 10 or may be 15 years when we started? Is Digital Ocean, Linode not a cloud provider. They were the VPS provider at the time.
I think in the end I agree with one of the argument, as long as these VPS providers give you a VPS that is charged per hour or per seconds, then they are cloud. Which ultimately is a server that is easily scaled up or down and charged on a time usage basis, when VPS at the time were a fixed monthly price.
Compilation speed isn’t that much of a factor of language as far as I can understand. It is more related to how optimization is done and how machine code is generated.
Also obviously it is about how fast the actual implementation of the compiler/build-system is.
> Definitely true when using VC++ with C++20 modules and MSBuild.
Lol, sorry, but as soon as MSBuild is involved the compiler can be infinitely fast and you'd still need to be waiting for the build. Also the main problem of MSVC is the slow linker, and that isn't fixed by C++ modules. This is also the first time I'm hearing that C++ modules actually help with compilation speed in real world projects - the best I've heard so far is that they're a bit faster than precompiled header but not by much, which simply isn't good enough for typical C++ projects.
What is the compile and link perfomance that you get then? Numbers on table... I know that even with MSVC, single file rebuild+link of C code at about 100 KLOC/second should be well possible.
You keep posting about obscure products like whatever UML Editor that noone cares about, why would I listen to what they say, and why do you not even link anything to look up?
FWIW, IME at least Nim isn't particularly fast when building, at least when compared to C projects. E.g. in the sokol-nim bindings I'm seeing build timings like:
32743 lines; 0.953s
...building 32k lines of code in a second really isn't fast on an M1 Mac, and that's for a debug build without optimization.
I would actually rate Neo having higher repairability. It is simply much better design and built even from a repair point of view. Speaker, Keyboard and Battery are the most common thing for repairing. It is only RAM and SSD that is better, but that is a different set of trade offs with performance and battery usage compromise.
We don't know what replacement keyboards will cost. It's probably cheaper than the $600 MBP topcase repairs that are normally warranted, but I doubt it will reach the $20 mark of Thinkpad or Framework repairs. The "repairable design" is a bartering chit for enterprise customers, not a marketing stunt for the Framework crowd. Those people are right to ignore Apple's promises here, the battle is only partway won.
Unless they have hardware encoder and decoder design done in parallel, otherwise it would be 2028 before a hardware block design is done and 2030 for the earliest product to ship with it. In reality I think 2031 or 2032 is more likely.
And I have been saying the same for quite some time that 20-30% for a generational codec improvement isn't worth it. I think they originally aimed at 50%, and then 40% and then 30%.
reply