I think it is about half due to variable refresh rate and less than half due to hardware efficiency improvements, and maybe 10% due to a larger battery. The 12 and 12 Pro got 11 hours of streaming playback, the 13 gets 15 hours with it's larger battery and more efficient hardware, while the 13 Pro gets 20 hours with it's variable refresh rate.

It appears that the battery on the 13 and 13 Pro are close in size since they both get 75 hours of music playback. The battery is slightly larger on the 13 than the 12 which got 65 hours of music. (I assume hardware efficiency would have very little effect on AAC decoding at this point, there couldn't have been much left to optimize.)

So all in all, looks like variable refresh will be a potentially very impressive feature, both for smoother UI and better battery life.

> So all in all, looks like variable refresh will be a potentially very impressive feature, both for smoother UI and better battery life.

And I think coming soon to macOS Monterey too. If we thought the M1 MBPs had impressive battery life at launch...

I think you’re thinking of “adaptive sync”, which is more of a gaming thing and only works when the app is fullscreened.

> I think you’re thinking of “adaptive sync”

Adaptive sync and variable refresh rate are the same thing.

> only works when the app is fullscreened

Video of the monterey beta shows it works without being fullscreened. https://www.reddit.com/r/macgaming/comments/o1954n/adaptive_...

I don't know to what extent the display itself needs to be different, but hopefully Apple planned ahead.

> Video of the monterey beta shows it works without being fullscreened.

That is so confusing. Doesn't that mean you could create a malicious video which basically freezes the display for multiple seconds?

And wouldn't your interface feel super laggy if it's reduced to something like 30fps? That's what most content is produced with, right?

Doing other stuff with the system likely preempts the slowdown. Someone in another thread reported that just moving their mouse increased refresh rate.

I can't see it as an option for my MBP, though I do have the monitor connected in a roundabout way, through a dock. Monitor did support FreeSync, which is the open one too, so wondering what's going on there. Monterey Beta 6 here (along with all the pains that that version brought).

We can roughly calculate the expected improvement based on “non-streaming” factors (8h extra/28h*25h=7.14h of expected improvements that include things like screen refresh rate, decoding and better battery) so therefore 25h new streaming video, minus 12h previous streaming battery, minus 7h expected improvement leaves about 5 hours of streaming performance improvements (WiFi/Network/bug fixes/???). Seems like a lot.

Perhaps they’re assuming a cinematic frame rate of 24fps for streaming video and matching the refresh rate to that versus whatever refresh rate an iPhone 12 Pro has - guessing 60hz?

Still seems a big increase but maybe the combination of the variable refresh display, larger battery and refined 5nm node (TSMC 5NP) all add up to something substantial?

I was wondering if this was also factoring 5G in given last year’s 5G modems were noted as particularly power hungry. I’m guessing Apple is testing on WiFi though.

5g modems are still power-hungry which is why iPhone will still default to '5G Auto' which uses LTE most of the time, and switches to 5g for data-hungry tasks.

They highlighted dynamic refresh rate on screen. So screen can run at 30FPS (half of normal speed) if you are streaming 30FPS content (which many folks do). Or even 24FPS (which now won't need to be converted - nice!).

None of these factors explain why they closed the large gap between offline and online video playback

Maybe a hw decoder? (These already exist, but I mean, really tightly integrated with the browser.) Or some other offloading to hardware?

That would be my best guess

They did say during the conference that the new chip had a new video encoder/decider, so that sounds plausible.

Maybe just more efficient since the A14 already had AV1 and HEVC support.

https://www.cpu-monkey.com/en/igpu-apple_a14-180

The cinematic mode is done by recording a depth map (calculated using the ISP and Neural Engine?) alongside the regular video. On older phones you could do this using the SDK, but iirc it was a much lower resolution depth map (like 480p or less?).

Given that they've also added ProRes encode/decode, it's likely fair to assume that they've redone the entire codec hardware.

So yeah, this is my long-winded way of agreeing with you that it is indeed more efficient.

> the A14 already had AV1

Uh, I'm gonna need to see a reputable citation for that claim.

Yeah I tried to find another source and could not find anything. Does anybody else know? I just see a lot of posts complaining about CPU usage with AV1 on a M1 macbook.

Sure they have hw decoders. But they are used in all cases, and get fed the same input. Either some software optimization how network is used or a different modem (potentially doing also more TCP offload stuff) seems more likely.

I would think the newer 5G modem would help, too.

I’d have thought the streaming test is done over wi-fi. Maybe the Targeted Wake Time in WiFi 6 combined with higher bandwidth can account for the difference.

Maybe. 5G still uses more power than 4G over long duration, if both are enough for streaming. 5G power usage benefits come when you download something, and it simply takes less time.

Can’t you achieve the same results then by pretending that one long stream is just a bunch of independent chunks and download them separately in bursts? No need to trickle it the entire time.

Afaik that's how video streaming works. You can text it in YouTube and look at buffer length for example.

Edit: my objection is incorrect. We’re in fact saying the same thing. I misread a previous post :/

Not if the broadcast is (eg) HLS[0], so I think the proper answer is: “it depends.”

[0] https://en.wikipedia.org/wiki/HTTP_Live_Streaming?wprov=sfti...

I am surprised to see someone saying HLS wouldn't work this way. I'm not up to speed on the latest in HLS, but when I used it circa ten years ago, HLS worked by providing parts of a stream as individual video files, so I'd expect this is more true for HLS than a single-file-as-a-stream, not less. Videos were divided into fixed-length files, e.g. 10 seconds each. The playlist file saying what video files to use could list all of the file names up front for every provided quality level.

Indeed you’re right (and this was my understanding too) - I misread what a previous commenter was intending. I thought they were saying most broadcasts are 1-piece blobs, thus good for 5G bursting. My experience w HLS is indeed some small-number-of-seconds frames at a time. I guess I’m not sure here whether 5G is more battery-efficient or not. “Fast-enough” is all that’s required, so I guess it’s just the calculus of energy/bytes and how long the radio can sleep between segments. Seems very circumstantial to me…

If you're watching a live stream, there won't be all that many seconds you can buffer.

Maybe that means it spends less time buffering so smaller total power footprint?

My ip12 has shown 1.5 Gbps, that’s 4 hours of Netflix content per second…

That's "only" 187.5MB

The variable refresh rate is what enables the huge battery life improvement. The iPhone 12 has to update its screen 60 times per second, even though movies are shot at 24 frames per second. That means it's showing you the same frame 2 or 3 times, but initiating an entire redraw operation to do so.

The new screen can just leave the image up for 1/24th of a second and then draw the next frame.

the numbers shown compare video, streamed, versus video downloaded. this is specifically an improvement on video streaming. i don't see where this theory that variable refresh rate would make a difference would come from.

there may be variable refresh rate differences! i just don't think that's what this comparison is highlighting.

> i don't see where this theory that variable refresh rate would make a difference would come from

People are comparing between the 13 and 13 Pro which get the same battery life for audio playback. There are very few other stated differences between them.

Aggressive pre-caching so the wireless modem isn't turned-on as long?

The 8h difference would be rather attributed to the dynamic refresh rate.

There's a big difference between under-clocking phones with older batteries to prevent random shutoff, and what you're claiming.

And this is exactly where I feel HN had really gone downhill. The quality of the comments keeps decreasing. There’s plenty of technical information out there on the underclocking to prevent reboot issue, and years ago I would have expected this audience to be well versed in it before commenting.

All good things just come to an end, I suppose. The question is where to go instead?

The comment was quickly flagged by other users and is now dead. I'm not sure the hysteria is warranted, you're never going to find a public site where nobody ever posts anything dumb.

I find that https://lobste.rs has similar technical stories I enjoy.

Their account/comment system (a tree of trust based who invited whom to the site) does a good job of limiting drive-by negativity and other unpleasantries.

I don't have an account there yet due to being shy and not knowing many techy persons IRL I might get an invite from. (If anyone wants to invite me I'd appreciate it)

Yeah, this place is staggeringly quickly heading towards reddit clone.

Marley suggesting something akin to planned obsolescence get hive mind downvoted. Yar har capitalism and apple.

Apple releases same product for years now, them having a strategy for x years forward is not outrageous claim