Update recording server and headful image

[Sayan-]

• Uses static releases so to use ffmpeg 7.x instead of the provided
• Drops 1080p resolution since it's fairly compute intensive
• Small tweaks to the recording server

---

TL;DR

Updated the recording server and Chromium headful image to use FFmpeg 7.x, reduce video resolution to 768p for performance, and improve FFmpeg shutdown reliability.

Why we made these changes

To reduce computational load by dropping high-resolution recording (1080p), leverage a newer FFmpeg version (7.x) for better features and stability via static builds, and enhance the robustness of the recording server's FFmpeg process management.

What changed?

• Chromium Headful Image: Switched to manual installation of FFmpeg 7.0.x from static builds, reduced default desktop resolution from 1920x1080 to 1024x768, and added a neko server readiness check in wrapper.sh.
• Recording Server: Reduced maximum allowed frame rate from 120 to 20, refined FFmpeg shutdown logic with extended timeouts and improved error propagation, and added new video encoding arguments (-profile:v high, -pix_fmt yuv420p) for better web compatibility.
• API Definitions: Synchronized oapi.go and openapi.yaml to reflect updated server API specifications.

Validation

• Updated config_test.go to reflect new frame rate limits.
• Modified ffmeg_test.go to expect specific exit status errors during FFmpeg recorder stop, indicating refined shutdown handling.
  

[mesa-dot-dev]

What Changed

This PR focuses on improving the performance and reliability of the recording server. Key changes include updating the chromium-headful image to use a static build of FFmpeg 7.x and reducing the default screen resolution from 1080p to 1024x768 to lower compute requirements. The server configuration has been updated to cap the recording frame rate at 20 FPS. Additionally, the FFmpeg shutdown process was made more robust with longer timeouts, and video encoding arguments (-profile:v high, -pix_fmt yuv420p) were added to improve web compatibility.

Risks / Concerns

A significant security concern was identified in the images/chromium-headful/Dockerfile. The new process for installing FFmpeg downloads a binary from an external source without any integrity verification. As noted in the review on line 96, this could allow for the execution of a malicious binary if the source is compromised. It is highly recommended to add a checksum validation step (e.g., sha256sum) to mitigate this risk.

^{9 files reviewed | 1 comments | Review on Mesa | Edit Reviewer Settings}

[mesa-dot-dev]

Security concern: Downloading and executing binaries from an external source without integrity verification. Consider adding checksum validation or using a specific versioned URL with known checksums to ensure the downloaded binary hasn't been tampered with.

Suggested change

	URL="https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz"; \
	# install ffmpeg manually since the version available in apt is from the 4.x branch due to #drama.
	# as of writing these static builds will be the latest 7.0.x release.
	RUN set -eux; \
	URL="https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-amd64-static.tar.xz"; \
	EXPECTED_SHA256="<insert_known_checksum_here>"; \
	echo "Downloading FFmpeg static build from $URL"; \
	curl -fsSL "$URL" -o /tmp/ffmpeg.tar.xz; \
	echo "$EXPECTED_SHA256 /tmp/ffmpeg.tar.xz" | sha256sum -c -; \
	tar -xJf /tmp/ffmpeg.tar.xz -C /tmp; \
	install -m755 /tmp/ffmpeg-*/ffmpeg /usr/local/bin/ffmpeg; \
	install -m755 /tmp/ffmpeg-*/ffprobe /usr/local/bin/ffprobe; \
	rm -rf /tmp/ffmpeg*

^{Type: Security | Severity: High}