It's sad to see so many people are blinded by this. The current situation of RCS is just that Google saw Apple disguised iMessage as SMS and wanted to do the same. RCS is merely a vehicle for Google.
They could just layer their own chat platform on top of Google Messages but we all saw how Google's IM business went along: Chat, Hangouts, Alo, Meet etc. So they muddied the water so deep (to a carrier level) to make it look like it's Apple's issue for not adopting RCS. And people actually fall for it.
Nobody wanted RCS. Even carriers don't want to maintain RCS. They just use Jibe. And that's exactly what Google wanted. My RCS communication with friends don't even show up in carrier's usage. How is that ever different from iMessage...
You know who chose to selfhost their own RCS server? Yes, Chinese carriers! They call it 5G Message. New ad delivery channel for businesses hooray! Instead of plain text and a link, now your campaigns can even have MENUs inside! I can send SMS to a Chinese number, I can send iMessage to a Chinese number, but I can't send RCS. Truly "Universal" profile.
It’s to compare core architecture brother. The fact is Apple’s core has best IPC, has best efficiency, has best peak performance.
And you put out a long long long post to point out what everyone understands: putting more cores in and running at a lower frequency would yield better efficiency at full load… that’s why we got to the point in today’s x86 laptops, a single core running at full speed already exceeds sustained multicore power target (28-60w depend on device class) because Intel and AMD has no other way to up the performance other than adding more cores.
Cinebench 2024 takes considerably longer to finish and would saturate the whatever possible heat headroom the device has. It can be treated as an accurate reading.
Chart below is the aggregated result from CPU-monkey, Geekerwan's chip analysis, devices of my own and various other reports.
Apple M1 series 3.2GHz 5W: ~115
Apple M2 series 3.5GHz 5W: ~120
Apple M3 series 4GHz 7.5W: ~140
Apple M4 series 4.4GHz 7.5W: ~170
Apple M5 may be the first ever CPU to near ~200pts on Cinebench single-core while still maintaining less than 10W of core power draw. Competitors lose on all fronts by about 2 or even 3 generations at their respective device class.
3.2.1 (vii) Apps may enable individual users to give a monetary gift to another individual without using in-app purchase, provided that (a) the gift is a completely optional choice by the giver, and (b) 100% of the funds go to the receiver of the gift. However, a gift that is connected to or associated at any point in time with receiving digital content or services must use in-app purchase.
Many years ago in China where WeChat said Apple was about to collect fees on reader's donation to writer's article (whether paywalled or not). WeChat was taking a cut on such donation. Later WeChat agreed to not taking such cut on donations and the payment not fullfilled by in-app purchase but rather WeChat Pay (as a means of fund transfer).
However, in the case of Patreon, often people are not donating to the creator, they are paying money to gain access to the creators' work (early access, exclusive membership content, etc.), thus Patreon is selling the product produced by creators.
Edit: I want to add that there should be a cut for Apple in this case, but not 30% or 15% (via subscription).
> I've tried to feed screenshots to ffmpeg and other tools, and it's just... unusable. It works, but consumes way too much resources.
Did you try to use the hardware encoder? Modern computers have chips to accelerate/offload video encode/decode. Your 2019 Mac has Intel GPU for H.264 and HEVC hw encoder, also it has an T2 co-processor that can also encode HEVC video.
If you don't supply specific encoders (with _videotoolbox suffix on Mac) via -c:v then ffmpeg will default to sw encoder, which consumes CPU.
> how to scan the screen and send only parts of the screen that have been updated
You'll be reinventing video codecs with interframe compression.
> Also, curious to hear about video encoding efficiency vs 60x JPEG creation. Is it comparable?
I see that you are comparing pixel by pixel for each image to dedupe and also resizing the image to 1280px. Also the image has to be encoded to JPEG. All of the above are done in CPU. In essense you implemented Motion JPEG. Below is a command to allow you to evaluate a more effecient ffmpeg setup.
ffmpeg \
-f avfoundation -i "<screen device index>:<audio device index>" \ # specific to mac
https://www.hanyi.com.cn/adminlte/ueditor/image/20230906/169...