[WIP] Warn and reduce high-bitrate video uploads

Overview

Users frequently upload videos with very high bitrates to Studio — both via ricecooker (cheffers) and manual uploads through the UI. This leads to excessive storage usage, increased bandwidth consumption, and poor rendering performance for end users. This task covers surfacing warnings to uploaders when bitrate is too high and using MediaBunny to automatically reduce bitrates, across both ricecooker and the Studio UI.

Complexity: High

Context

High-bitrate video uploads are a recurring problem across both cheffers (ricecooker) and manual Studio uploaders. These files consume disproportionate storage and bandwidth, and degrade the rendering experience for end users — particularly those on low-bandwidth or low-resource devices.

There are also storage cost implications: as the team explores charging for larger storage (>50GB), helping users reduce file sizes proactively would allow more users to stay within free-tier limits.

Early team explorations (Jessica, Samson, Laura, Allan) surfaced a few considerations:

• In-browser compression is technically feasible and fast (Samson tested a media compression library with positive results on a mid-range device)
• UX around compression needs care — users can currently get stuck with no clear exit, too many mixed progress indicators, and no background processing
• Communication to users matters: they should be made aware of high bitrate before performing an action, not mid-upload

Slack analysis thread: https://learningequality.slack.com/archives/C0LKEH6NM/p1620143479136800

The Change

When a user uploads a video with a bitrate above a defined threshold (TBD), Studio should block the upload and present a warning that explains the issue. The user should be offered two options:

• Compress the video (recommended, default) — use MediaBunny to reduce the bitrate before completing the upload
• Proceed anyway — override the block and upload the file as-is

If the user chooses to override, they should be clearly informed of the implications: increased storage usage, higher bandwidth consumption, and potential performance degradation for end users on low-resource or low-bandwidth devices.

This applies not only to standalone video files but also to HTML5 zip archives containing embedded video — the bitrate check should inspect media files within archives, not just top-level uploads.

The compression option should be clearly surfaced as the preferred path. The ricecooker equivalent will be handled in a separate issue in the ricecooker repo.

Out of Scope

• Handling videos that have already been uploaded with high bitrates — this will be assessed and addressed separately
• Ricecooker-side detection and compression (tracked in a separate issue in the ricecooker repo)

Open Questions

• Messaging when compression may not be enough: Studio currently blocks uploads that exceed the max file size or the user's remaining storage quota. In these cases, compression might reduce the file enough to succeed, but this cannot be guaranteed. What should the messaging be — should compression still be offered as a "worth trying" option, or should the user be directed elsewhere? (TBD)

Acceptance Criteria

General

• When a user uploads a video exceeding the bitrate threshold (TBD), the upload is blocked and a warning modal is presented
• The modal is blocking — the user cannot proceed until they select one of the two options (compress or override)
• The compress option is the recommended and default selection
• Selecting compress triggers MediaBunny to reduce the video bitrate before completing the upload
• Selecting override informs the user of the implications (storage, bandwidth, and performance impact for end users) before allowing the upload to proceed
• The bitrate threshold is configurable (to be determined)
• Bitrate detection applies to embedded video files inside HTML5 zip archives, not only top-level video uploads

Testing

• Upload a high-bitrate video and verify the blocking modal appears
• Verify compress path completes successfully and the uploaded file has a reduced bitrate
• Verify override path surfaces the implications message and completes the upload with the original file
• Upload an HTML5 zip archive containing a high-bitrate embedded video and verify the blocking modal appears

References

• Clearing house issue
• Slack analysis thread: https://learningequality.slack.com/archives/C0LKEH6NM/p1620143479136800
• MediaBunny documentation: https://mediabunny.dev/

Start with the Studio UI upload flow and the MediaBunny documentation, then trace how HTML5 zip archives expose embedded video files. Done means a configurable bitrate threshold blocks high-bitrate uploads, offers compression or an informed override, and covers the listed standalone-video and archive-upload tests.