DEV Community: panda

Test the Video Upload Journey, Not Just the Upload Button

panda — Thu, 29 Oct 2026 08:52:14 +0000

A file picker can work perfectly while the video workflow around it is broken. The upload completes, a progress bar reaches the end, and the recipient opens a file with no sound or text too small to read.

Disclosure: I work on VideoBee. This article was written with AI assistance and fact-checked against the references below. The examples are hypothetical; they are not customer incidents, implementation details, or measured results from that product.

When building a video upload feature, treat file selection, acceptance, processing, playback, and recovery as separate things to check. A small test matrix makes those boundaries easier to see.

Start with the promise your interface makes

Imagine a hypothetical feedback portal that accepts short screen recordings. Before choosing test files, write down what the portal promises: which inputs it accepts, what limits apply, what happens after upload, and where the result should play.

“Supports video” is too vague to test. “Accepts these documented inputs, shows a useful error for unsupported files, and provides a playable review copy in these target environments” gives the team something observable.

Keep that contract near the interface. People should not have to discover the size limit after sending most of a large file. If processing changes the original, explain what the downloadable result represents.

Separate the file extension from the media inside

MP4 is a container format. The audio and video streams inside it have their own encoding formats. A filename ending in .mp4 does not, by itself, describe every characteristic that affects playback. MDN's media container guide explains this distinction.

For each test fixture, record what you know: source, container, audio and video encoding when available, dimensions, duration, and file size. Keep unknown values explicitly unknown. Do not infer an encoding from the filename.

This turns “the MP4 failed” into a more useful observation: a particular fixture failed in a particular environment. It also helps avoid repeatedly testing several files that happen to exercise the same easy case.

Build a small matrix with a reason for every row

Start with a few representative fixtures rather than a folder full of random videos. Each row should answer a specific question.

Fixture	Question	What to inspect
A short recording with speech	Does the normal path work?	Upload, processing, picture, and sound
A recording with small UI labels	Is the delivered copy still useful?	Readability at the recipient's viewing size
A portrait clip	Does the layout handle its shape?	Orientation, framing, and player controls
A valid file near the documented size boundary	Is the limit applied consistently?	Actual acceptance and the displayed explanation
A file just beyond that boundary	Is rejection understandable?	Error text, retained state, and next action
An unsupported or invalid fixture	Does failure remain controlled?	A clear rejection rather than a stuck workflow

Add a fixture when it covers a meaningful gap. A missing audio track, for example, should not automatically be treated as the same situation as audio that exists but cannot be played.

Use synthetic or explicitly cleared material. A reproducible fixture should not contain a customer's desktop, an internal recording, or an accidental notification.

Test the picker and the actual acceptance rules

The HTML accept attribute helps guide file selection. It is not a substitute for validation. As MDN's file input documentation explains, users may be able to override the picker filter, so the application still needs appropriate server-side validation when accepting uploads.

Check the paths your interface actually offers. If it supports drag and drop as well as a file picker, verify both against the same contract. A helpful filter in one path should not hide inconsistent handling in another.

Treat an invalid test fixture as expected input to a test, not an invitation to accept everything. The useful outcome is a controlled response with an explanation and a way forward.

Make recovery part of the feature

An interrupted connection is a separate case from an unsupported file. A processing failure is separate from an upload failure. Give these states different test rows and ask what the person can do next.

For the hypothetical portal, check what happens when someone cancels, selects another file, navigates away, or retries after a failure. Does the interface make the active task clear? Could an old error be mistaken for the status of the replacement file?

Do not label a workflow “resumable” merely because a Retry button exists. Test the behavior you intend to promise, and describe that behavior precisely.

Finish where the recipient finishes

Open the actual delivered copy in each environment you support. Check its beginning, a meaningful point in the middle, and its ending. Listen if audio matters. Pause on the smallest important detail. Confirm that access permissions allow the intended recipient to retrieve it.

Record the fixture, environment, expected result, observed result, and date. Keep observations separate from explanations: “audio was absent in this player” is evidence; a proposed cause still needs investigation.

The upload button is the entrance to the workflow. A useful test matrix follows the file far enough to show whether the person on the other end can actually use it.

Make Bug-Report Videos Useful, Not Just Small

panda — Thu, 29 Oct 2026 08:32:02 +0000

A bug-report video has a job: help another person understand what happened and reproduce it. A smaller attachment helps with delivery, but a tiny, unreadable recording can still be a poor bug report.

Disclosure: I work on VideoBee. This is a tool-independent workflow, not a product recommendation. This article was written with the assistance of AI. The examples below are hypothetical, not reports of incidents or measured results.

Start with the question the recording should answer

Before recording, write one sentence: “After this action, I expected this result, but this happened instead.” That sentence defines the useful boundaries of the video. It also stops a recording from becoming a tour of every tab that happened to be open.

For example, imagine a settings page where saving appears to work, but the old value returns after a refresh. The recording needs to show the starting value, the edit, the save response, and the refresh. A clip that starts after the edit may hide the very condition someone needs to reproduce the problem.

Keep the written report alongside the video. Include the relevant application version, browser, operating system, account role, and starting state. Include only details that matter to the issue. A video is evidence; it should not be the only place the reproduction instructions exist.

Prepare a safe, repeatable starting state

Use sample data and a test account where possible. Close unrelated tabs, hide notifications, and check which account is active before recording. A clean desktop reduces distractions, but the more important reason is avoiding accidental disclosure.

Inspect names, email addresses, customer records, internal URLs, access tokens, and details in developer tools. A brief appearance still counts as exposure. Prefer replacing sensitive values before recording over trying to hide them during editing.

Cropping is not a complete privacy check. A filename, spoken narration, or browser suggestion can contain information outside the obvious part of the screen. Review the whole recording, including its audio. Follow your team's approved handling process before placing any recording in an external service or sharing destination.

Also record the setup in text. “Fresh account with no saved filters” is a different starting state from “existing account with three filters.” If setup is complicated, describe it separately rather than making every recipient watch several minutes of preparation.

Keep the causal chain intact

A useful sequence is: starting state, trigger, visible response, and evidence of the unexpected result. Give the viewer a moment to read each important state. A cursor moving quickly across the screen is not a substitute for an explanation.

Trimming can remove an accidental pause or an unrelated detour. It should not erase a step that changes the result. In the hypothetical settings example, cutting the refresh would remove the distinction between a failed save and a display that simply has not updated yet.

If waiting is relevant, preserve or describe it. A loading problem may depend on elapsed time. If you shorten a wait, add a note such as “A 40-second wait is shortened here.” Do not present two edited moments as an uninterrupted sequence when the gap could affect interpretation.

Sometimes two clips are clearer: one showing the minimal reproduction, another containing diagnostic detail. Label them by purpose. The first answers “what breaks?” The second can answer “what else was happening?” Neither needs to pretend to contain the entire investigation.

Optimize for the smallest important detail

The deciding quality check is not whether the desktop looks attractive. It is whether the viewer can read the error, identify the selected control, and distinguish the old value from the new one.

Record the relevant application area at a sensible size. Avoid capturing an entire high-resolution desktop when the issue occupies one small panel. However, keep enough context to explain navigation and state. A tight crop can make a dropdown readable while hiding which page it belongs to.

When reducing file size, change one setting at a time and inspect the downloaded result. Lower resolution can make small labels illegible. Lower frame rate may be acceptable for a mostly static settings page but can obscure a brief flicker or animation defect. There is no universal preset that preserves every kind of evidence.

Watch the output at the size a recipient is likely to use. Pause on the smallest meaningful text and check the moment where the bug occurs. A file that opens successfully has passed a compatibility check, not a usefulness check.

Give file size a budget

Check the actual destination's current limit instead of assuming that every issue tracker or chat app accepts the same attachment. Leave some margin below that limit, and retain the original recording separately.

For a rough estimate, file size is approximately duration multiplied by average total bitrate, divided by eight. That is a planning relationship, not an exact export guarantee: audio and container overhead also need space.

Consider a hypothetical 30-second clip with an 8 MB budget, using decimal megabytes. The approximate total bitrate budget is 8 × 8 ÷ 30, or 2.13 megabits per second. The video stream cannot automatically consume all of that if the file also carries audio. The example explains the tradeoff; it is not a recommended setting or a measured result.

Shortening an irrelevant segment can reduce the amount of material that needs encoding. Compressing harder changes how the remaining material is represented. Choose between those actions based on the evidence you must preserve, then check the final file's actual size.

Make the handoff work without a live explanation

Use a descriptive filename and place the expected and actual results next to the attachment. If the issue appears at a particular point, add a timestamp. Keep essential facts in text so someone can search, quote, and update the report later.

Before attaching, check:

Can someone reach the starting state from the written instructions?
Are the trigger and unexpected result both visible?
Are important labels and errors readable in the exported file?
Are edits and shortened waits explained where they matter?
Have sensitive visuals, audio, and identifying details been checked?
Does the file open and fit the destination's current limit?
Is the original retained if more detail becomes necessary?

A strong bug-report video removes guessing. Its value comes from preserving the right evidence and making the next person's investigation easier. File size matters because the evidence has to arrive. Clarity matters because, once it arrives, someone has to use it.

I Built a Private Online Video Cutter in 2 Weeks: Why I Chose WASM Over Server-Side Processing

panda — Thu, 07 May 2026 08:47:31 +0000

Hi everyone! 👋
Over the past two weeks, I’ve been working on a side project called Video Cutter — a fast, free, and privacy-focused online tool for quick video edits with no watermarks or forced sign-ups.

💡 The Problem
We’ve all been there: you need to trim a 10-second clip from a screen recording, but every "free" tool you find online feels like a trap:

The "Sign-up" Wall: "Enter your email to download your file."
The Watermark: A giant logo over your content unless you pay.
The Privacy Gap: You have to upload your video to a random server, which is a dealbreaker for sensitive or professional content. I wanted something different: Upload → Cut → Download. No accounts, no watermarks, and most importantly, no data ever leaving your computer.

🧱 The Tech Stack
The project is built with:

Frontend: Nuxt (for a fast, SEO-friendly static UI).
Styling: A minimalist Glassmorphism design (lots of light green and clean gradients).
Video Processing: FFmpeg.wasm (FFmpeg running directly in the browser via WebAssembly). The entire app is static and deployed on a CDN. There is no backend server involved in the video processing.

⚙️ Why I Chose Frontend (WASM) Over Backend Processing
Unlike many tools that move processing to the server for speed, I deliberately chose to keep everything on the client side. Here’s why:

Instant Privacy: Since the video is processed locally via WebAssembly, the file never hits a server. This is a huge win for privacy-conscious users.
Zero Upload Time: Traditional tools require you to wait for a 500MB file to upload before you can even start cutting. With WASM, the "upload" is instant because it's just loading the file into browser memory.
Scalability & Cost: Because the user's CPU does the heavy lifting, I don't need expensive server clusters with GPUs. This allows me to keep the tool 100% free and unlimited.

🧪 Lessons Learned

WASM is the Future of Utility Tools: For simple tasks like cutting, rotating, or flipping, the browser is now powerful enough to handle the job without a backend.
UI/UX is a Feature: Users don't want a full-blown editor for a 5-second trim. Keeping the UI minimalist and "Glassmorphic" makes the tool feel lightweight and modern.
Memory Management is Hard: Handling 4K files in a browser tab is tricky. I had to spend a lot of time optimizing how FFmpeg.wasm handles memory to prevent crashes on older machines.

🌍 Try It Out
If you need to quickly trim a video without the cloud-processing headache, feel free to give it a spin:

👉 AudioCut
It’s completely free, no watermarks, and your data stays with you. I’d love to hear your feedback, especially regarding browser performance or any UX improvements you'd suggest!

How are you handling browser-side media processing? Let's chat in the comments!