News for hackers. Stuff that matters.
Re:Web Browser Engineering by pstrateman on Tuesday October 15, 2024 @09:56AM (#41848643)
> As an aside, video decoding is offloaded onto hardware, so it's not as battery intensive as it used to be.

This is technically but not usefully true with most videos on the web today.

The video decode itself is accelerated, but each frame passes through JavaScript to be composited.

The only time video is fully hardware decoded is when it's a simple video element to a static video file.

Re:Web Browser Engineering by pjc50 on Tuesday October 15, 2024 @10:50AM (#41849217)
> The video decode itself is accelerated, but each frame passes through JavaScript to be composited

I don't think that's true, and it's even less true once DRM video is involved - it becomes very difficult to get other software on the machine to even see the video, at least on Windows. You can very occasionally see bugs where the hardware accelerated playback ends up in a different place to where the browser thinks the video should have been put, too.

What does happen is the video data gets reassembled in Javascript (e.g. Video.js) because the native player doesn't support HLS. Not quite the same thing. It's just reformatting MPEG-TS to the similar but not identical MP4. Oddly, the browser in my LG TV does play HLS video natively, and I think Safari does?

Re:Web Browser Engineering by afavour on Tuesday October 15, 2024 @10:15AM (#41848852)
> not usefully true with most videos on the web today

> The only time video is fully hardware decoded is when it's a simple video element to a static video file.

These seem in disagreement to me. The vast majority of videos on the web are simple video elements going to static video files. It is not usual for each frame to pass through JavaScript before being displayed.

Re:Web Browser Engineering by pstrateman on Tuesday October 15, 2024 @03:14PM (#41852079)
Most of the things you think of as static video files (say youtube) are actually video segments operating more or less exactly the way live streams work.
Re:Web Browser Engineering by afavour on Wednesday October 16, 2024 @01:11PM (#41861406)
Yes, I know. But the frames still aren't passed through JavaScript.
Re:Web Browser Engineering by Sesse__ on Wednesday October 16, 2024 @07:23AM (#41857848)
The decoded frames do not pass through JavaScript. The compressed data may (e.g. if you are using the Media Source API).
Re:Web Browser Engineering by pavpanchekha on Tuesday October 15, 2024 @10:07AM (#41848766)
I think by "JavaScript" here you mean rendering—that's partially true. In macOS and Windows these days (also I think Linux with GTK4 on Wayland, though only in a limited way), the window manager is itself composited and a window can send a small display list to that window manager for it to composite. In that case, it's possible to actually have the video decoding to happen entirely in hardware and never have the browser directly interact with decoded video bits. That said usually the window manager compositor is pretty limited and the browser will only do this when the stars align. The sort of things that can break it are any kind of weird clipping, transparency, or effects applied to the videos.
Re:Web Browser Engineering by incrudible on Tuesday October 15, 2024 @10:09AM (#41848790)
> each frame passes through JavaScript to be composited

What do you mean by that? There is no Javascript doing the actual compositing, and the actual compositing is (usually) hardware accelerated.