fix(#264): read raw pixels from canvas for VideoFrame to avoid silent failures on Linux

[GuilhermeFaga]

Description

Fix green static output for MP4 export.

Motivation

On some linux OSs the MP4 output is corrupted.

Type of Change

• New Feature
• Bug Fix
• Refactor / Code Cleanup
• Documentation Update
• Other (please specify)

Related Issue(s)

#264

Testing

$ npm install
$ npm run build
# run generated AppImage
$ ./release/1.3.0/Openscreen-Linux-1.3.0.AppImage
# export video as MP4

Checklist

• I have performed a self-review of my code.
• I have added any necessary screenshots or videos.
• I have linked related issue(s) and updated the changelog if applicable.

---

Thank you for contributing!

Summary by CodeRabbit

• Refactor
  • Improved internal video export frame construction logic for better stability and control over pixel data handling.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: cafe67ca-f150-4c9e-beac-4e84d033a4ed

📥 Commits

Reviewing files that changed from the base of the PR and between 2f36160 and 914a3c7.

📒 Files selected for processing (1)

• src/lib/exporter/videoExporter.ts

---

📝 Walkthrough

Walkthrough

The video exporter's frame construction was refactored to extract pixel data from the canvas using the 2D context's getImageData method and create VideoFrame objects from the underlying ArrayBuffer with explicit format and dimension parameters, instead of passing the canvas directly to the VideoFrame constructor.

Changes

Cohort / File(s)	Summary
Video Frame Construction src/lib/exporter/videoExporter.ts	Updated per-frame VideoFrame instantiation to derive pixel data via canvas 2D context getImageData and construct from ArrayBuffer with explicit format: "RGBA" and codedWidth/codedHeight parameters. Removed TypeScript colorSpace suppression while preserving timestamp, duration, and colorSpace values.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A canvas once cast in mysterious ways,
Now strips to its pixels in clearer displays!
With getImageData we see every hue,
The frame flows with clarity—fresh-rendered and true! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly describes the main change: reading raw pixels from canvas for VideoFrame to fix Linux compatibility issues.
Description check	✅ Passed	The description covers all required template sections including Description, Motivation, Type of Change, Related Issue, Testing, and Checklist, with sufficient detail for the fix.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 914a3c7f7b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Scope raw-pixel fallback to affected Linux cases

This change forces a synchronous getImageData readback and CPU-side copy for every frame in every environment, even though the comment and issue describe a Linux-specific shared-image failure. On unaffected platforms this removes the prior zero-copy VideoFrame(canvas, ...) path and can significantly reduce export throughput (especially at high resolutions/long videos), so the workaround should be gated (e.g., Linux-only or runtime fallback after a detected failure) rather than always-on.

Useful? React with 👍 / 👎.