Strip audio track from hero-video.mp4 (fixes Firefox suspend inhibitor)

[danzatt]

Problem

The hero video (static/videos/hero-video.mp4) on flatcar.org is purely decorative — embedded with autoplay muted loop in themes/flatcar/layouts/partials/hero.html via the video-player.html partial. But the source MP4 ships with an unused AAC audio track (192 kbps, ~32 s).

Firefox treats any autoplaying <video> element that has an audio track as "playing video" and registers a suspend inhibitor with the desktop session over D-Bus (org.freedesktop.PowerManagement.Inhibit), regardless of the muted attribute. With a flatcar.org tab open you can observe:

$ gnome-session-inhibit --list
org.mozilla.firefox: Playing video (suspend)

User-visible impact: anyone leaving a flatcar.org tab open in Firefox cannot suspend their machine — laptop lid close, idle suspend, and the GNOME "Suspend" menu all silently fail until the tab is closed or backgrounded.

Fix

Strip the unused audio track. The video stream is copied as-is (no re-encode, no quality loss):

ffmpeg -i hero-video.mp4 -an -c:v copy -movflags +faststart hero-video.new.mp4

Result

• Suspend inhibitor goes away — verified locally with gnome-session-inhibit --list before/after.
• Asset shrinks ~770 KB (42,360,511 → 41,565,472 bytes).
• No visible change — the video was muted already.
• +faststart keeps the moov atom at the front so the browser can start playback before the full file arrives.

Verification

$ ffprobe -v error -show_streams -select_streams a static/videos/hero-video.mp4
(no output — no audio streams)

[danzatt]

I've just tested this PR locally and it does the trick. However, it would be better to switch away from 40MB video altogether.

[chewi]

Thanks, I initially thought this couldn't be avoided, but I didn't realise it was the audio.

I agree though that 40MB is really excessive. It's currently encoded as H.264, which isn't the most efficient and is not a free codec. VP9 in a WebM is a better choice. Re-encoding with ffmpeg -i hero-video.mp4 -an -movflags +faststart hero-video.webm brings it down to a more palatable 7.5MB. It's not obviously worse, and the retro effect makes the quality not that important anyway. We'd get a better result if we encoded from the source video, although I suspect this is the source video.