DEV Community: Max/Wang

What Is FSR? A Practical Look at FSR Video Upscaling for Browser-Based Tools

Max/Wang — Sun, 13 Sep 2026 14:13:49 +0000

If you've ever used a browser-based video upscaler that doesn't require uploading your file to a server, there's a good chance FSR is the tech running under the hood. It powers a lot of lightweight, fast upscaling tools that work on almost any device — no GPU required. Here's what FSR actually is, how the different versions differ, and why its earliest version turns out to be a surprisingly good fit for client-side, WASM-based tools.

What is FSR?

FSR stands for FidelityFX Super Resolution, an upscaling technology built by AMD. It started as a gaming feature: render a game at a lower resolution (say 1080p), then let FSR reconstruct the missing detail to display it at a higher resolution (like 4K) — cutting GPU load while keeping the image close to native quality.

The same core idea has since been applied outside of gaming, to video and images in general, which is why it now shows up in browser-based upscaling tools too.

The key difference between FSR and Nvidia's DLSS is that FSR doesn't need dedicated AI hardware like Nvidia's Tensor Cores. The earlier FSR versions run on almost any GPU — Intel graphics, older cards, whatever — which is exactly why it's so easy to port into cross-platform, cross-device apps (including ones compiled to WASM).

The FSR generations, briefly

FSR 1 — spatial upscaling, no AI. Looks at a single frame and processes it in two steps: EASU (edge-adaptive upscaling that interpolates detail more intelligently around edges) and RCAS (contrast-adaptive sharpening applied afterward). No motion vectors, no previous frames, no model — just an algorithm. That makes it extremely light, and it's the version that actually runs well inside WebAssembly in a browser.
FSR 2 — temporal upscaling, still no AI. Uses data from previous frames plus motion vectors to reconstruct detail more accurately. Better quality, but it needs motion data — fine for a game engine that always has it, much harder for a standalone video file.
FSR 3 — adds frame generation. Keeps FSR 2's upscaling core and inserts synthetic frames between real ones to boost FPS.
FSR 4 — a full switch to machine learning. Runs on the dedicated AI cores of AMD's RDNA4 GPUs (Radeon RX 9000 series). Quality is close to DLSS, but it only runs on that specific new hardware — it loses the "runs on anything" advantage of the earlier versions.

AMD is reportedly also working on a next-gen version (codename "Redstone") for a fully neural rendering pipeline, but that's real-time gaming tech, not something you'd deploy in a browser.

FSR for video vs. FSR for games

This is the part that's easy to mix up. In-game FSR runs in real time, tightly wired into the engine so it can pull motion vectors and depth-buffer data — information only a game engine has on hand.

Applied to video or still images, a tool doesn't have any of that internal data. All it has is the input file. That's why video/image tools rely on FSR's spatial branch — the FSR 1 approach, processing each frame independently through EASU + RCAS — rather than the temporal versions, which need motion data a plain video file simply doesn't carry.

AMD also has RSR (Radeon Super Resolution), which is essentially FSR 1 running at the driver level to upscale anything on screen — including video playing in YouTube or VLC. It's the closest thing to "FSR for video" without needing dedicated app support.

Why FSR fits browser-based, client-side tools so well

If you're building (or evaluating) a video upscaler that runs entirely client-side, with no file ever touching a server, going with FSR's spatial branch over a heavier AI model (Real-ESRGAN, waifu2x, Topaz Video AI, etc.) makes practical sense:

No model to ship. AI upscalers usually come with deep learning models that are tens to hundreds of MB, need to be downloaded to the browser, and run through inference — resource-heavy. FSR's spatial approach is just math (edge detection + sharpening), so it compiles down to compact WASM that runs fast even on weaker machines.
No GPU dependency. Since it doesn't touch AI/Tensor cores, it runs fine on an ordinary CPU through WASM — important since not every visitor has a strong GPU, and browsers have limited hardware-acceleration access anyway.
Frame-independent processing fits a "no upload" architecture. No motion vectors, no shared state between frames — everything can be processed locally, which is exactly what a fully client-side tool needs.
Quality/speed tradeoff that's usually worth it. Detail reconstruction isn't as sharp as a dedicated AI model or FSR 4, but it's enough to meaningfully reduce blur/pixelation, and it runs many times faster.

Comparison table

Method	How it works	Pros	Cons
Classic interpolation (Bicubic, Lanczos, etc.)	Computes new pixels via a pure math interpolation formula	Extremely lightweight, built into most image libraries	Looks blurry, no real detail reconstruction
FSR (spatial — FSR 1)	Edge detection + adaptive sharpening	Lightweight, no AI needed, cross-platform, WASM-friendly	Lower quality than dedicated AI upscalers
AI upscaler (Real-ESRGAN, waifu2x, etc.)	Deep learning model trained to reconstruct missing detail	Strong detail reconstruction, especially on low-quality sources	Heavy models, resource-intensive, slow on weaker machines
FSR 4 (AI, new AMD GPUs only)	ML model on dedicated AI cores	Quality near top-tier AI upscaling, real-time optimized	Needs specific GPU hardware — no browser, no plain CPU

Takeaway

FSR was built to solve a gaming problem — less GPU load, still-sharp images — but the simple algorithmic core of FSR 1 opened up a genuinely useful side application: fast, lightweight upscaling that runs almost anywhere, including inside a browser via WebAssembly, with the file never leaving the device. That combination of speed and near-universal compatibility is exactly why it keeps showing up in modern client-side video tools.

If you're working on anything WASM + media processing, curious to hear what upscaling/compression approaches others have landed on for the "no server upload" constraint — drop a comment below.

References:

How Many Times Can You Compress a Video Before It Looks Bad?

Max/Wang — Sun, 13 Sep 2026 13:37:11 +0000

If a compressed video looks worse than you expected, the problem usually isn't the compressor — it's that the file was already compressed once before you touched it.

The result looks worse than it should — here's why

You compress a video, and it comes out blockier or softer than you expected, even on a setting that's supposed to keep quality close to the original. Nine times out of ten, the file you fed into the compressor wasn't actually the original — it was already a compressed copy, and you just compressed it a second time without realizing it.

This happens constantly without anyone noticing, because the first compression pass usually isn't a choice you make on purpose. You record a video, a messaging app or social platform re-compresses it the moment you upload or send it, you download that version back down later, and then run it through a compressor again to hit a size limit somewhere else. By the time you're looking at the final result, it's had two or three rounds of lossy compression stacked on top of each other — and each one throws away more detail than the last, in a way that adds up faster than most people expect.

Why compression loss compounds instead of staying flat

Every time a video is compressed, the encoder makes judgment calls about which detail to keep and which to discard, based on what it can actually see in that specific file at that moment. The first pass discards genuine picture detail — fine texture, subtle gradients, motion blur, small variations in color — because that's the least noticeable place to save space when the source is clean. Second and later passes don't have that untouched detail to work with anymore. The encoder is now looking at a file that already has some blockiness and softness baked into it, and it has to make the same kind of decisions again, except this time there's less real information left to preserve.

Here's the part that makes it worse than simply "losing a bit more each time": some of what the second pass now treats as real picture detail is actually just artifacts left over from the first compression. Blocky edges around a face, slight color banding in a sky, a faint checkerboard pattern in a dark scene — the encoder doesn't know these came from a previous compression pass rather than the original footage, so it spends bits trying to preserve them as if they mattered, which leaves even less budget for the parts of the image that actually do.

It's the same idea as photocopying a photocopy. The first copy loses a little sharpness around the edges of the text. Copy that copy, and you're not starting from the clean original — you're compounding the loss that's already there, and the machine has no way of knowing which smudges were in the first copy versus the real page. Video compression works the same way, just with motion and color instead of ink on paper.

Where the extra compression passes sneak in

Recording — Phones and screen recorders already compress footage as they save it. This is the real original, and it's already been through one encoding pass before you've done anything at all.
Uploading somewhere first — Instagram, WhatsApp sent "as video," Discord, and most messaging apps re-encode whatever you send through them, usually at a lower bitrate than you'd choose yourself, to keep their own storage and bandwidth costs down.
Downloading that version back — If you then save the file from the app or platform instead of pulling it from your own camera roll, you're now working from the re-compressed copy, not the source — and there's often no visual clue that this happened.
Editing and re-exporting — Trimming or adding captions in a phone editing app usually means a full re-encode of the whole clip, even for a one-second cut — another pass, whether or not you changed the picture itself.
Compressing again to hit a new limit — Squeezing that already-compressed, already-re-exported file down further for a different platform's size limit is the pass where the accumulated loss finally becomes visible to the naked eye.

None of these individual steps is unreasonable on its own — trimming a clip, sending it to a friend, then needing it smaller for a different app is a completely normal sequence of events. The problem is that each step quietly re-encodes the file, and nothing in the process warns you that it's happening. By the time you notice the quality drop, you're usually several steps removed from the original file and it's not obvious which step actually caused it.

How to tell if a file has already been compressed

A few practical signs are worth checking before you compress something a second time:

If the video came from anywhere other than your own camera roll or recording software — downloaded from a chat, saved from a social app, pulled off someone else's share link — assume it's already a compressed copy rather than a source file.
Zooming into a still frame and looking for faint blocky squares in flat areas like skies or walls, or a slightly smeared look around fast-moving edges, is a reasonably reliable tell that a file has already been through at least one lossy pass, even if it still looks fine at normal viewing size.
File size relative to length and resolution is another clue: a five-minute 1080p clip sitting at only 15MB has almost certainly already been compressed hard by whatever app touched it last, since an untouched original at that resolution and length is normally many times larger.

How to avoid it

The fix is simpler than it sounds: always compress from the earliest, least-processed copy of the file you can find — usually the one still sitting in your camera roll or original recording folder, not a version you re-downloaded from somewhere else. If you know a video is headed to more than one place with different size limits, compress once at the lowest target size you'll actually need and reuse that single file, rather than compressing a fresh copy for each platform starting from an already-compressed one each time.

It also helps to match the compression level to what the video is actually for. If there's any chance you'll re-edit or re-export a clip later — adding captions, trimming it further, repurposing it for a different platform — keep it at a lighter setting the first time. SquishyFile's "Light" level trims redundant data without pushing the bitrate down aggressively, leaving more headroom before a second pass becomes visible, compared to jumping straight to the smallest possible file. Save "Max squish" for the last step before sending, once you know there's no next re-encode coming after it.

If storage allows, it's worth keeping the original, uncompressed recording around for a while even after you've shared a compressed version — a video you can always compress again from scratch is a lot more forgiving than one where the only copy left has already been through two or three rounds of lossy encoding.

FAQ

Is there a hard number of times I can compress a video?
Not a fixed one — it depends on how aggressive each pass is and how much motion or fine detail the footage has to begin with. A few light passes on simple footage can look fine; two or three aggressive passes on anything with texture or motion usually won't.

Does re-compressing the same file with the same settings make it worse each time?
Yes, even with identical settings, because the encoder is working from a file that already lost some detail last time — there's less real information to preserve on each subsequent pass, even though the settings you're choosing haven't changed.

If a platform re-compresses my upload anyway, is compressing it myself first pointless?
No — starting from a smaller, well-compressed file usually means the platform's own re-encode has less work to do and causes noticeably less additional damage than feeding it a huge, high-bitrate original the platform then has to crush down on its own.

Does SquishyFile compress the same file twice if I run it through the tool again?
Each run compresses whatever file you drop in at that moment — if that file is already a compressed export from a previous run, yes, that's a second pass. Keep your original source file around if you might need to compress it differently later.

What's the safest setting for a video I might need again later?
Light compression, and keep the original uncompressed file if you have the storage for it. You can always compress harder later if you need a smaller file; you can't get lost detail back once it's gone.

Can I visually tell how many times a video has been compressed?
Not precisely, but blockiness in flat areas, smeared fast motion, and a file size that's unusually small for the resolution and length are all signs of at least one prior pass — worth checking before you compress it again.

Need to compress a video right now without losing more detail than necessary? SquishyFile runs entirely in your browser — no uploads, no server round-trip, just drag, pick a level, and download.

The first shader I ever wrote drew nothing at all

Max/Wang — Sat, 12 Sep 2026 14:36:44 +0000

Not an error. Not a crash. Just a blank black canvas, for about two hours, while I quietly assumed WebGL itself was broken. It wasn't — I'd forgotten to bind one uniform, the GPU had every reason in the world to draw nothing, and it did exactly that without complaint. That's usually how the first week with shaders goes: coming from normal programming, where a missing variable throws an exception you can read, and landing in a world where a mistake just... produces silence. No stack trace. No pixel. Nothing to grep for.

The reason it's disorienting is that a shader isn't really "code" in the sense a JavaScript or Python function is. It's a tiny program, usually a few dozen lines, that the GPU runs an enormous number of times in parallel, and it has almost no memory of anything outside itself. Once that model clicks, a lot of GPU behavior that looks like magic — real-time video effects, live filters, a game rendering a complex scene at 144 frames a second — turns out to be a fairly simple idea, repeated an absurd number of times per second.

Two programs, two completely different jobs

Every WebGL draw call runs two shader programs back to back, and they're not doing the same kind of work at all.

The vertex shader runs once per vertex — a corner point of a triangle, since everything the GPU draws eventually decomposes into triangles. Its only job is geometry: given this point's input data, where does it end up on screen? That's it. It doesn't know about color, lighting, or texture in any deep sense; it just outputs a position, and the vertex shader for a single triangle might run only three times total.

Once every vertex of a triangle has a screen position, a fixed-function stage called the rasterizer figures out which pixels fall inside that triangle. This part isn't programmable — it's baked into the GPU's silicon — and it hands off every pixel it finds to the second program.

The fragment shader (called a "pixel shader" if you came from DirectX) runs once for every one of those pixels, and this is where basically all the interesting work happens: color, lighting, textures, effects. A fragment shader has no idea it's one of two million running this frame. It gets fed whatever data got interpolated across the triangle for its specific location, and its only job is to answer one question — what color is this pixel? — and hand back an answer.

Here's a trick that still feels a little illegal the first time you see it: if all you need is to process a full-screen image — which is exactly what a video filter or a post-processing effect needs — you don't need a vertex buffer, an index buffer, or even a real triangle mesh. You draw one triangle, deliberately oversized so it covers the entire screen and then some, computed directly from the vertex's built-in ID with no input data at all:

// A single triangle, built from gl_VertexID alone,
// big enough to cover the whole screen. No buffers needed.
void main() {
  vec2 pos = vec2((gl_VertexID << 1) & 2, gl_VertexID & 2);
  gl_Position = vec4(pos * 2.0 - 1.0, 0.0, 1.0);
  vUv = pos; // passed to the fragment shader, interpolated per-pixel
}

Three vertices, zero setup, and every pixel on screen gets covered exactly once. The part that got cut off past the visible viewport just gets clipped away for free by the rasterizer. It's the standard way to run a "process this whole image" shader, and once you've seen it you start noticing it's what almost every real-time video or image effect is quietly built on.

How data actually gets into a shader

None of this is useful if a shader can only see itself — it needs a way to read in the image you're processing and whatever settings you want to control. GLSL gives you exactly two doors in, and picking the right one matters.

A uniform is a value that's the same for every single pixel in a given draw call — you set it once from JavaScript before drawing, and every invocation of the fragment shader that frame sees the identical number. This is the natural home for anything a slider controls: scanline intensity, grain amount, how strong a chromatic-aberration effect should be. The GPU doesn't recompute it per pixel; it's just a constant sitting there while two million pixels each read the same value and do something different with it based on their own position.

A texture is the other door, and it's how the actual image gets in — the current video frame, uploaded to the GPU as a 2D grid of color data. The fragment shader doesn't loop over that grid; it samples a single texel at whatever coordinate corresponds to the pixel it's currently responsible for, using UV coordinates that got interpolated across the triangle from the vertex shader. Want to blur something, or detect an edge? Sample a few neighboring coordinates around your own position instead of just one, and combine them. That's the entire trick behind most of what looks like a complicated visual effect — one texture, a handful of nearby samples, and some arithmetic.

Between those two — uniforms for "how strong" and a texture for "what image" — you can express almost any real-time filter without ever touching the CPU again once the frame is uploaded.

Why this thing is absurdly fast

A CPU is built to run one instruction stream really well, with a handful of cores doing a handful of different things. A GPU is built for the opposite bet entirely: thousands of much simpler cores, all running the exact same instructions at the exact same time, just on different pieces of data. That architecture is useless for most general-purpose code, which is full of branches and dependencies between steps. It's perfect for a fragment shader, because a fragment shader is designed, on purpose, to never need to know what any other pixel is doing.

That independence is the entire performance story. A 1920×1080 frame is a little over two million pixels. The fragment shader doesn't run two million times in some patient loop — the GPU dispatches huge batches of pixels across its cores simultaneously, and because no pixel's answer depends on any other pixel's answer, there's nothing stopping it from happening at once. That's what makes a full-frame effect — color grading, a blur, a chromatic aberration pass, a whole filtered look — something a GPU finishes in a fraction of a millisecond, at a resolution and frame rate that would make the same math on a CPU, in a naive per-pixel loop, visibly chug.

It's also why shader code looks weirdly restrictive if you're used to normal programming — no dynamic memory allocation, loops generally need to know their bounds ahead of time, and branching that diverges wildly between neighboring pixels can quietly tank performance even when it still produces a correct result. Those aren't arbitrary rules. They're the price of admission for running the same tiny program a couple million times a frame, sixty times a second, without the whole thing falling over.

Where this actually shows up: real-time video and image effects

This is the part that made shaders click for me as more than a graphics-programming curiosity. Take any video effect you've seen applied live — scanlines, film grain, an edge-detection sketch look, a thermal false-color pass, chromatic bleed — and the practical way to do it in a browser is exactly the fullscreen-triangle setup above: decode a video frame into a texture, run one fragment shader pass over it, and read the result back out. Every single pixel gets the same treatment independently — sample a color, run some math on it, maybe sample a couple of neighboring pixels for something like an edge or a blur, write the output — and the GPU chews through the whole frame in parallel before the next one is even ready to decode.

Compare that to doing it the naive way: a JavaScript loop over a canvas's raw pixel array, checking each pixel one at a time on the CPU. It'll produce the same image, technically, but at maybe a few frames per second on anything past a tiny thumbnail, because you've thrown away the one property — total independence between pixels — that makes the parallel version fast in the first place. The math for a lot of these effects isn't even that complicated. A basic edge detector is a handful of neighboring-pixel samples and a threshold. What makes it usable in real time, on a full video, is entirely about running that small piece of math on the right kind of hardware, in the way that hardware was actually built to run it.

Why I ended up building a shader-based filter tool

This is more or less the rabbit hole that led to SquishyFile's video filter tool. I wanted a VHS-style effect — scanlines, tape warmth, that slightly degraded camcorder color bleed — plus a few more artistic looks like pencil sketch and thermal vision, with the preview updating live as you tweak it, not "upload, wait, hope it looks right." A CPU-side loop was never going to hit a watchable frame rate. A WebGL2 fragment shader, running one pass per frame with the same fullscreen-triangle setup above, handles it easily — drag a slider, the shader re-runs, the preview updates instantly, because the per-pixel math is cheap and the hardware is built to run all of it at once.

The side benefit is that nothing ever leaves your browser. The frame becomes a GPU texture locally, the shader runs locally, the render gets encoded back to video locally — no server ever sees your footage. If you want to see the fullscreen-triangle trick above actually doing something, the tool has ten styles — six VHS and camcorder presets plus pencil sketch, cross-hatch, thermal vision and neon — with a live preview so you can judge the effect on your own clip before rendering the final file.

What's Actually Inside a Video File?

Max/Wang — Sat, 12 Sep 2026 14:26:11 +0000

If you pause a video, you see a complete, sharp image.

It’s easy to assume that the video file contains that image somewhere as a complete picture.

Usually, it doesn't.

A compressed video is much closer to a collection of instructions for reconstructing frames than it is to a folder full of photographs. Once you understand that, a few annoying video behaviors suddenly make a lot more sense:

Why scrubbing sometimes jumps slightly away from the exact position
Why an extracted frame can look worse than the frame you saw during playback
Why cutting one second from a video can require re-encoding the entire thing
Why some trims are instant and lossless while others take much longer

The interesting part is that all of these behaviors come from basically the same mechanism.

A video isn't really a stack of photos

Raw camera footage is, in a sense, a sequence of images.

But storing every frame as a completely independent image would make compressed video absurdly large.

Imagine a static shot where almost nothing changes between frames. If the camera records 30 frames per second, there is very little reason to store the entire background 30 times.

Instead, modern video codecs such as H.264, HEVC, and AV1 take advantage of the similarity between neighboring frames.

Some frames contain a complete image.

Others mostly describe how the image has changed.

And that's where I-frames, P-frames, and B-frames come in.

The three main frame types

I-frames

An I-frame, or intra-coded frame, is a complete image that can be decoded independently.

It's the closest thing to a traditional photograph inside a compressed video.

If a decoder has an I-frame, it has enough information to reconstruct that frame without needing another frame first.

The downside is that I-frames are relatively expensive to store.

That's why a video doesn't normally contain a complete I-frame for every single frame.

P-frames

P-frames are predicted frames.

Instead of storing another complete image, a P-frame describes changes relative to previously decoded reference frames.

For a mostly static scene, that can save a huge amount of data.

Suppose someone is sitting in front of a stationary background. Between two frames, the wall, desk, and most of the person's body might be almost identical.

There's no reason to encode all of that information again.

The encoder can describe the changes instead.

This is why most frames in a typical compressed video aren't self-contained pictures.

B-frames

B-frames take prediction a step further.

They can use information from frames before and after them.

The "after" part sounds strange at first. How can a frame refer to something that hasn't happened yet?

The encoder and decoder don't necessarily process frames in the same order that you watch them.

The encoder can arrange the necessary reference frames so that the decoder has the information it needs when reconstructing the final playback sequence.

B-frames can therefore compress very efficiently because they have more information available for prediction.

You normally never notice any of this while watching a video.

Your player handles the reconstruction automatically.

It becomes interesting when you stop doing normal playback.

This is where the GOP comes in

These frames aren't just thrown into the file randomly.

They're organized into groups called GOPs — Groups of Pictures.

A simplified GOP might look something like this:

I  B  B  P  B  B  P  B  B  P  I

The exact structure varies by codec and encoder, but the important idea is that an I-frame provides a new independent starting point, followed by frames that can depend on other frames.

GOP length is a trade-off.

More I-frames generally means more independently stored pictures and therefore more data.

Longer GOPs can improve compression efficiency because the encoder doesn't have to store as many expensive I-frames.

But longer GOPs also make certain operations less convenient.

And that's when things like seeking and editing start getting weird.

Why does video seeking sometimes feel inaccurate?

Say you drag the timeline to exactly 01:23.450.

You expect the player to show you precisely that frame.

But that frame might be a P-frame or B-frame.

It can't necessarily be decoded by itself.

The player may need to find an earlier I-frame and then decode all the necessary frames between that keyframe and your requested position.

Conceptually:

I → B → B → P → B → P → B → B → [your frame]

The player starts from the I-frame and reconstructs forward until it reaches the requested frame.

That's computational work.

Some software prioritizes accuracy and does this reconstruction.

Other implementations may prioritize speed and seek to a nearby keyframe first, which can make the scrubber appear to land slightly before or after where you expected.

So when a video player doesn't seem perfectly precise while scrubbing, it isn't necessarily broken.

It may simply be dealing with the way the video was encoded.

Why can an extracted frame look worse than the video?

This one is particularly unintuitive.

You pause a video and see a fairly sharp image.

Then you extract that exact frame as a JPEG or PNG.

And somehow the exported still looks softer or more blocky.

What happened?

The frame you extracted might have been a predicted frame.

During playback, that frame exists as part of a rapidly changing sequence. Your visual system doesn't spend much time inspecting the individual frame.

But when you turn it into a standalone image, all of its compression artifacts become much easier to notice.

Fast motion can make this even more obvious.

A predicted frame following a large amount of movement has more changes to encode. The encoder can compress those changes aggressively because, during normal playback, the viewer isn't expected to stop and inspect that single frame.

Once you extract it as a still, that assumption disappears.

Now you're staring directly at the frame.

This is one reason why moving the extraction point forward or backward by a few frames can sometimes produce a noticeably better still.

You're not necessarily finding a "better moment."

You're simply landing on a frame that happened to survive compression a little better.

The surprising part: trimming a video

Here's where this frame structure becomes much more important.

Suppose you have a ten-minute video and want to remove the first second.

It sounds like a trivial operation.

Why should an editor have to do anything complicated? Just remove the first second and keep everything else, right?

The problem is that your cut might happen in the middle of a GOP.

Imagine the beginning of the remaining video looks like this:

I → B → B → P → B → P → B → ...
        ↑
     cut here

If the first frame you're keeping depends on information from a frame you just removed, that frame is no longer valid on its own.

The editor can't simply throw away the first second and copy the remaining compressed data unchanged.

It needs to create a new valid sequence.

That usually means:

Decode the relevant video data
Apply the cut
Encode the resulting frames again
Create new reference frames and predictions

And that's why a seemingly tiny edit can trigger a full export.

But sometimes trimming is instant

There is an important exception.

If your cut happens to land exactly on an existing I-frame, the remaining video may already have a valid independent starting point.

In that case, software can sometimes perform a stream copy or remux instead of re-encoding the video.

The actual picture data doesn't need to change.

The software can essentially rearrange the existing encoded streams inside a new container.

That's extremely fast and doesn't introduce another generation of lossy compression.

The catch is that you don't get to choose arbitrary frame-accurate cut points when doing this.

If the cut falls between keyframes, you generally lose that advantage.

This is why two apparently identical "trim this video" operations can behave completely differently.

The difference may simply be where the keyframes happen to be.

One simple way to think about it

A useful mental model is to imagine a video like this:

[I] [changes] [changes] [changes] [I] [changes] [changes] [changes] [I]

The I-frames are complete starting points.

The other frames are instructions that depend on information around them.

During playback, your video player quietly reconstructs everything.

During editing, you start interacting with those dependencies.

That's why:

What you see	What's happening
Scrubbing isn't perfectly precise	The player may need to seek from a nearby keyframe
An extracted frame looks rough	The frame may be heavily compressed or predicted
A tiny trim takes a long time	The cut may fall inside a GOP and require re-encoding
Some trims are nearly instant	The cut may align with existing keyframes
Motion-heavy frames look worse as stills	More changes have to be represented in the predicted frame

Once you know about GOPs, these behaviors stop looking random.

Does a longer GOP mean worse video quality?

Not necessarily.

A longer GOP doesn't automatically mean lower visual quality.

It's primarily a compression and access trade-off.

Fewer I-frames can reduce the amount of data required, while predicted frames take advantage of similarities between neighboring frames.

The downside is that random access becomes more complicated, because there are fewer independent starting points.

This matters for things like:

Video editing
Seeking
Streaming
Frame extraction
Scrubbing
Fast random access

For ordinary playback, you might never notice the difference.

Why codecs are designed this way

It can be tempting to look at all of this and think: wouldn't it be easier if every frame were just a complete image?

Yes — but the resulting files would be enormous.

The whole point of inter-frame compression is that consecutive frames are usually highly redundant.

A stationary background doesn't need to be encoded from scratch 30 times every second.

A talking head doesn't require the entire scene to be completely re-described for every frame.

Video compression takes advantage of that redundancy.

The price is that not every frame is independently useful.

That's not a flaw.

It's the fundamental trade-off that makes compressed video practical.

The useful takeaway

You don't need to understand GOP structures to watch YouTube or record a video on your phone.

But once you start extracting frames or editing video, this little bit of codec knowledge becomes surprisingly useful.

If a frame looks worse than expected, try a few nearby frames.

If a simple trim takes much longer than expected, the cut probably isn't landing on a convenient keyframe.

And if one video can be trimmed almost instantly while another takes ages to export, the difference may have nothing to do with the length of the video at all.

It can come down to something you normally never see:

where the keyframes are.

That's one of the interesting things about compressed video. What looks like a simple sequence of pictures on screen is actually a carefully constructed dependency graph underneath.

Building a Browser-Based Video Upscaler with AI-Assisted Coding

Max/Wang — Fri, 11 Sep 2026 15:15:07 +0000

I finally finished the video upscaler for SquishyFile.

Honestly, this was probably the most frustrating tool I've built so far.

I want to start with one thing, though: if you think "vibe coding" means describing an idea in one sentence, letting AI generate everything, and coming back two hours later to a finished product — that's not how it went for me.

At least not with DeepSeek.

I used DeepSeek mainly because it's cheap. Claude Code is noticeably better at coding in my experience, but the cost adds up quickly when you're using it for a project like this.

With DeepSeek, I could usually get something running fairly quickly.

Then the fun started.

Fix one bug, another one appeared. Fix that one, and something else broke. Run another test, get a completely different result.

And video processing makes debugging even more painful because "it runs" doesn't necessarily mean "it works."

Sometimes the colors were wrong. Sometimes the output video was rotated. Sometimes the aspect ratio was messed up. Sometimes the result looked nothing like the original video.

A fix that worked perfectly with one video could break another one.

So the workflow became something like:

Write code → run it → find something broken → explain it to the AI → change the code → run it again.

Over and over.

For almost a week.

That's also why I don't really understand the "I built this in two hours with AI" posts I sometimes see. Maybe they're building something simple, or maybe I'm just particularly bad at this. But once you get into browser-based video processing, the first two hours can disappear just trying to figure out why the output is wrong.

Why run it in the browser?

The main reason is money.

SquishyFile is free and I'm not charging users for the tool. I also don't want to run expensive GPU infrastructure just to process videos for a free service.

Video upscaling is especially GPU-heavy.

If every uploaded video had to go through a cloud GPU on RunPod, AWS, or something similar, the economics would get ugly very quickly. A few dozen concurrent users could generate a GPU bill that makes no sense for a free tool.

So I decided to take the other approach:

Run the model directly on the user's machine.

No video processing server on my side.

That creates a very different set of problems, though.

Now the tool has to deal with different browsers, different GPUs, different amounts of memory, different video formats, and devices that can range from a powerful desktop to a laptop that starts getting very warm after a few minutes of processing.

And all of that has to happen inside a browser.

The part where I almost gave up

There were a few points where I seriously considered abandoning the browser approach and just putting the processing on a server.

It would have made some things much easier.

But then I'd have to keep paying for GPU time every month for a free tool.

That didn't really make sense to me.

So I kept going back to the code.

Some bugs were straightforward. Others took a while to understand. Sometimes I found the problem myself and told the AI exactly what was happening. Other times I had to go back and forth with it for a while before we finally found the actual cause.

It wasn't exactly the effortless AI-assisted development experience you see in demos.

But eventually, it started working.

Then it worked with another video.

Then another one.

And eventually I had something I was comfortable shipping.

It's finally live

The video upscaler now runs directly on the user's device.

There's no need to upload the video to my server for processing, and the tool is free to use without a usage limit.

If you have an old low-resolution video, or a video that looks noticeably worse after being compressed by a social platform, you can give it a try:

SquishyFile Video Upscaler

The interesting part for me isn't really that AI helped write the code.

It's that AI made it possible for me to keep working on a problem that would have been much harder to tackle alone.

It just didn't make the problem disappear.

I still had to run the code, look at the broken output, figure out what was actually wrong, and keep pushing until it worked.

After nearly a week of doing that, I'm just glad the thing finally has a shape.

Browser-based DOCX to PDF converter using Pandoc and Typst (WASM)

Max/Wang — Thu, 12 Feb 2026 16:02:26 +0000

Hi Fr,

I built a Word-to-PDF converter that runs 100% in your browser. No files ever touch a server.

Link: https://toolkuai.com/word-to-pdf

The Stack

The challenge was handling the complex layout of .docx files without a heavy backend. I settled on a "double-engine" approach using WebAssembly:

Pandoc (WASM): Used to parse the DOCX structure and convert it into Typst code. I’m utilizing a WASI shim to run Pandoc's Haskell-compiled WASM in the browser.
Typst (WASM): Instead of using a heavy TeX engine, I used Typst's modern rendering engine to turn the intermediate code into a polished PDF.

Technical Highlights

Media Extraction: The tool extracts images from the DOCX file via Pandoc’s --extract-media, maps them into a virtual file system (WASI), and then passes them to Typst for final rendering.
Custom Fonts: To support multi-language characters (especially CJK), I’m side-loading custom fonts (GenYoGothic) into the Typst compiler within the worker.
Svelte 5: The UI is built with Svelte 5, leveraging its new runes ($state, $derived) for a very snappy, reactive file queue management.
Web Workers: All the heavy lifting (WASM instantiation and conversion) happens in a dedicated worker to keep the UI at a buttery 60fps.

Why Pandoc + Typst?

Pandoc is the swiss army knife of document conversion, but its direct PDF output usually requires a LaTeX distribution. By routing it through Typst, I can get high-quality PDF output with a much smaller WASM footprint and faster rendering times.

I’d love to hear your thoughts on the performance or any edge cases you find with complex DOCX layouts!

I Spent 3 Years in the App Store. Now I'm Building My First SaaS in Public.

Max/Wang — Mon, 06 Oct 2025 14:55:53 +0000

Hey devs!

For the last three years, my world has been Xcode, Swift, and the App Store's monetization maze. It's been an incredible learning experience, but I've always been curious about the web and the SaaS world—a completely different beast with its own rules.

Today, I'm finally diving in and sharing the start of a new public experiment: mktgrowkit.com.

So, What Did I Build?
At its core, https://mktgrowkit.com is a simple, free suite of marketing calculators (ROAS, CPM, etc.). I built it to scratch my own itch: I needed quick, no-fluff tools to make data-driven decisions for my apps without hitting a paywall or signing up for a complex platform.

The Tech Stack
As a mobile dev, jumping into the modern web ecosystem was fun. Here’s the stack I chose for the MVP:

Framework: Nuxt.js. I chose this specifically for the out-of-the-box Server-Side Rendering (SSR), which is crucial for my SEO-centric strategy.

Styling: Tailwind CSS. It allowed me to build the UI incredibly fast without writing a lot of custom CSS.

Deployment: Vercel. The seamless Git integration and global CDN made launching and iterating a breeze.

Backend: Currently static, but I'm using Supabase for some server-side logic and plan to integrate it more for future features.

The Real Challenge: From ASO to SEO
Building the tool was familiar territory. The real experiment is the challenge I've set for myself: Can I grow this from zero purely through Search Engine Optimization?

No paid ads, no big launch campaign. Just the long, slow grind of content creation, technical SEO (sitemaps, canonicals, Core Web Vitals), and authority building. It's a whole new world compared to the ASO (App Store Optimization) I'm used to. It feels daunting, but as an engineer, I'm excited by the technical challenge of it.

Why Build in Public?
I'm a huge believer in learning from others, so I'm committing to tracking this entire journey in public—the good, the bad, and the ugly. I'll be sharing traffic stats, keyword rankings, technical hurdles, and any lessons learned along the way.

I'd love to hear from other devs who have made a similar jump from mobile to web.

What was your biggest "aha!" moment or surprise?

Any advice on surviving the SEO grind?

If you want to follow the data and see how this experiment plays out, I'm posting all my updates on X (Twitter). I've created this pinned tweet to track the journey: [Link đến Pinned Tweet của bạn]

Thanks for reading!

I just launched TL;Dev, a curated collection of notes for developers and indie builders.

Max/Wang — Wed, 27 Aug 2025 14:38:14 +0000

Hey everyone,

Like many of you, I spend a lot of time on Reddit, X, and YouTube looking for interesting case studies and strategies. The problem is, there's too much content and not enough time. I'd save dozens of links intending to read them later, but that "later" never came.

So, I built a solution for myself called TL;Dev.

It's a simple, no-BS website where I personally curate and summarize the most valuable content into short, easy-to-read notes. The goal is to help developers and indie builders grasp the core ideas in minutes, not hours.

My site is covering everything from successful launches to costly failures.

It's 100% free, no paywall, no annoying pop-ups. Just content.

For those interested, it’s built with Astro and deployed on Cloudflare. It's ridiculously fast.

I'm posting here because I think it could be genuinely useful for this community, and I'd love to get your feedback on the site, the content, or any ideas you might have.

You can check it out here: https://tldev.co

Thanks for reading!!

How to Find Profitable App Ideas (Even If You Think Everything Already Exists)

Max/Wang — Fri, 28 Feb 2025 08:29:31 +0000

Finding a great app idea can feel impossible—especially when it seems like every idea has already been done. But the truth is, you don’t need a 100% original idea to succeed. You just need to build something that solves a real problem in a better way.

Why You Don’t Need a Completely Original App Idea

Many aspiring indie developers believe that success comes from launching a completely new, never-before-seen product. But in reality, most successful apps weren’t the first of their kind—they were just better, simpler, or more focused than existing solutions.

Think about physical products: there are dozens of energy drink brands, water bottles, and vanilla ice creams, yet all of them make millions. Apps work the same way.

How to Find a Profitable App Idea That Actually Works

Instead of chasing originality, focus on solving real problems for a well-defined audience. Here’s a proven framework to discover high-potential app ideas:

1. Start with a Niche You Understand Deeply

The best ideas come from inside knowledge of a specific market. If you personally experience a problem, chances are thousands of others do too.

What are the biggest challenges in industries you’re familiar with?
What daily annoyances do you or your colleagues face?
Have you ever said, “I wish there was an app for this”?

Start by identifying problems in an area where you already have expertise.

2. Study Communities to Discover Hidden Needs

Instead of forcing an idea, immerse yourself where your target audience hangs out:

Reddit, Discord, Slack, Twitter (X), and Facebook groups
Product review sites like G2, Capterra, and App Store reviews
Quora and niche forums where people ask for advice

Look for repeated frustrations or complaints about existing solutions. When you see the same pain point mentioned repeatedly, you’ve found a validated demand.

3. Improve on an Existing App Instead of Reinventing the Wheel

Rather than struggling to come up with a unique idea, find a popular app and make a better version:

Make it simpler, cheaper, or faster
Solve a missing pain point
Focus on a specific audience (e.g., a budgeting app tailored for freelancers)

Many successful startups started this way—Slack improved on workplace chat, Notion refined note-taking, and Duolingo made language learning more engaging.

4. Test Demand Before Writing a Single Line of Code

Before building, validate your idea:

✅ Post about it on social media and gauge interest
✅ Run a small paid ad campaign to see if people click
✅ Create a simple landing page and collect email signups
✅ Ask potential users directly in communities

If no one is excited, pivot or refine the idea before coding.

Four Must-Have Ingredients for a Successful App Idea

To maximize your chances of success, your app idea should check these boxes:

Easy to Build – Aim to launch an MVP within 30 days.
Solves a Clear Pain Point – The problem should be urgent and painful.
Has an Audience You Can Reach – If you don’t know where your users hang out, it’ll be hard to market.
Excites You Enough to Stay Committed – If you’re not passionate about it, you’ll quit too early.

The Proven Formula for Finding Profitable App Ideas

Identify a niche you know well
Find a real problem people complain about
Improve an existing solution or fill a gap
Test interest before coding
Launch, get feedback, and iterate

🚀 You don’t need the next "big idea"—just a product that solves a real problem for real users.

Ready to find your next app idea?

Start by diving into online communities and observing what people truly need!

Why Developers Struggle to Make Money with Apps (And How to Fix It)

Max/Wang — Thu, 27 Feb 2025 07:30:00 +0000

Developers love building things. We get excited about new ideas, start coding right away, and create something we think is amazing. But then… nothing happens.

📉 No downloads. No revenue. Just silence.

Why? Because we often forget to ask the most important question—Does anyone actually need this app?

Why Market Research Matters More Than Your Code

❌ Most developers build first and validate later. That’s a mistake.

Here’s how to avoid wasting months on an app no one wants:

✅ Analyze the market.

Look at similar apps. If an app in your niche is making money, that’s a strong sign of demand.
If there are zero competitors, be careful—maybe there’s no market.

✅ Read user reviews on the App Store.

1-2 star reviews = complaints & frustrations.
4-star reviews = users love the app but want improvements.
Find gaps and build a better alternative.

✅ Check ASO keywords.

Use Sensor Tower or AppTweak to see if people are searching for solutions like yours.
If search volume is low, validate on Reddit, Google Trends, or Facebook groups before building.

The Mistake I Made (And What I Learned)

I once spent a whole month building an app that I thought was genius.
Launched it… and nothing happened.

🚀 Not because the app was bad—but because nobody needed it.

💡 Don’t make the same mistake. Before writing a single line of code, validate your idea.

How I Built an iOS App That Made $1,400 in 90 Days (Lessons Learned)

Max/Wang — Wed, 26 Feb 2025 16:18:58 +0000

I started with zero downloads, no marketing, and no clue if my iOS app would make money.

📊 Fast forward 90 days:
💰 $1,400 revenue
📆 $347 in the last 30 days
📈 $2,850 total since launch

Not life-changing, but proof that even a small app can generate real income.

The process wasn’t smooth. I made mistakes, wasted time, and almost gave up. But after testing and refining, I found what actually works when it comes to making money with iOS apps.

🚀 6 Key Lessons I Learned
💡 1. Build What You Love, But Validate Demand
Most devs start with an idea they love, but that’s not enough. There has to be demand.
✅ Check Google Trends, Reddit, Twitter.
✅ Look at App Store reviews to see common complaints.
✅ If nobody is looking for it, don’t build it.

💡 2. Marketing is More Important Than Coding
Most devs think "build it and they will come." Nope. Without marketing, your app is invisible.
✅ ASO (App Store Optimization) matters.
✅ Running Apple Search Ads, even with a small budget, can make a huge difference.
✅ Leverage social media (Twitter, Reddit) to drive early traction.

💡 3. Monetization Matters From Day One
✅ Don’t just launch a free app and hope for ad revenue.
✅ Subscriptions are better for long-term revenue.
✅ In-App Purchases (IAPs) work well if you offer real value.

🎯 I go into full detail in this breakdown video:

💡 Thinking about launching an iOS app? Watch this before you start!

Unlocking the Power of App Intents: Prepare Your App for the AI Revolution

Max/Wang — Thu, 24 Oct 2024 08:53:17 +0000

The whispers in the tech world are getting louder: AI is poised to become a central player in the iOS ecosystem. As developers, we're always looking for ways to stay ahead of the curve, and App Intents might just be the key to unlocking the potential of this AI revolution. While often overlooked, App Intents offer a powerful way to expose our app's functionality to the broader operating system, including Siri, Spotlight, and Widgets.

Imagine a future where users can seamlessly interact with your app through natural language commands, effortlessly completing tasks without even opening the app. This is the promise of App Intents, and with the rise of AI, their importance is only set to grow.

Why App Intents Matter in an AI-Driven World

App Intents act as a bridge between your app and the system's intelligence, allowing Siri to understand and execute actions on behalf of the user. By defining clear intents and parameters, you empower Siri to perform tasks such as adding items to a shopping list, starting a workout, or sending a message, all through voice commands or automated shortcuts.

With Apple's increasing focus on AI, it's likely that Siri will become even more integrated into our daily lives. This means that apps that leverage App Intents will have a significant advantage, offering users a frictionless and intuitive experience.

A Practical Example: Building a Feature Wishlist with App Intents

Let's dive into a real-world example to see how App Intents work in practice. We'll create a simple app called "Features," which allows users to maintain a wishlist of features for Apple platforms. Using SwiftData and SwiftUI, we'll implement an App Intent that enables users to add new features to their wishlist using Siri.

Step 1: Defining the Data Models

First, we define our data models: Feature and Platform. A Feature has a title, description, and a corresponding Platform. The Platform is an enum representing various Apple platforms.

import SwiftUI
import SwiftData

// MARK: - Feature

@Model
class Feature {
    var id: UUID = UUID()
    var title: String = ""
    var featureDescription: String = ""
    var platform: Platform = .iphone

    init(
        title: String,
        featureDescription: String,
        platform: Platform
    ) {
        self.id = UUID()
        self.title = title
        self.featureDescription = featureDescription
        self.platform = platform
    }
}

To enable Siri to understand our Platform model, we make it conform to the AppEnum protocol. This involves providing display representations for both the type and its cases.

import SwiftUI
import AppIntents

// MARK: - Platform

enum Platform: String, CaseIterable, Identifiable, Codable, AppEnum {
    case allPlatforms = "All Platforms"
    case iphone = "iPhone"
    case ipad = "iPad"
    case applewatch = "Apple Watch"
    case visionPro = "Vision Pro"
    case mac = "Mac"
    case appletv = "Apple TV"

    var id: Self {
        return self
    }

    // ... (icon code omitted for brevity)

    static var typeDisplayRepresentation = TypeDisplayRepresentation(stringLiteral: "Platform")

    static var caseDisplayRepresentations: [Platform: DisplayRepresentation] = [
        .allPlatforms: "All Platforms",
        .iphone: "iPhone",
        .ipad: "iPad",
        .applewatch: "Apple Watch",
        .visionPro: "Vision Pro",
        .mac: "Mac",
        .appletv: "Apple TV"
    ]
}

Step 2: Managing Features with FeatureManager

Next, we create a FeatureManager class to handle the creation, retrieval, updating, and deletion of Feature objects.

import SwiftUI
import SwiftData

// MARK: - Feature Manager

class FeatureManager: ObservableObject {
    // ... (Properties and Init code omitted for brevity)

    func addFeature(title: String, description: String, platform: Platform) {
        withAnimation {
            let feature = Feature(
                title: title,
                featureDescription: description,
                platform: platform
            )
            modelContext?.insert(feature)
        }
    }

    // ... (deleteFeature code omitted for brevity)
}

Step 3: Creating the App Intent

Now, we define the CreateFeature App Intent, which allows users to add new features to their wishlist through Siri. We specify the intent's title, parameters, a summary of its action, and the code to perform when invoked.

import SwiftUI
import AppIntents

// MARK: - Create Feature App Intent

struct CreateFeature: AppIntent {
    // ... (Properties code omitted for brevity)

    @Parameter(title: "Platform", requestValueDialog: "Where would you like to see this feature?")
    var platform: Platform

    @Parameter(title: "Title", requestValueDialog: "What's the title of the feature?")
    var title: String

    @Parameter(title: "Description", requestValueDialog: "What's the description of the feature?")
    var description: String

    // ... (Summary code omitted for brevity)

    @MainActor
    func perform() async throws -> some IntentResult & ReturnsValue<String> {
        FeatureManager.shared.addFeature(
            title: title,
            description: description,
            platform: platform
        )
        return .result(value: "New Feature for \(platform.rawValue)\n\n\(title):\n\(description)")
    }
}

Step 4: Exposing the App Intent to Siri

Finally, we expose our CreateFeature App Intent to Siri through an AppShortcutsProvider. This involves defining an App Shortcut that links to our intent and providing phrases that users can say to trigger it.

import Foundation
import AppIntents

// MARK: - App Shortcuts

struct AppShortcuts: AppShortcutsProvider {
    @AppShortcutsBuilder
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: CreateFeature(),
            phrases: ["Make a New \(.applicationName)"],
            shortTitle: LocalizedStringResource(stringLiteral: "New Feature"),
            systemImageName: "apple.logo"
        )
    }
}

Key Takeaways

App Intents are crucial for integrating your app with system functionalities like Siri, Spotlight, and Widgets.
As AI becomes more prevalent in iOS, App Intents will play an even greater role in enhancing user experience.
By defining clear intents and parameters, you enable Siri to understand and execute actions within your app.
Investing time in learning and implementing App Intents can significantly improve your app's discoverability and user engagement.