[WIP] Warn and reduce high-bitrate video uploads

[akolson]

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

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.

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)

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)

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

References

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