Hacker News Reader

Comment by LolWolf | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com