DEV Community: Phoenix Labs

Why upscaling old low-res video makes it look worse, and the ffmpeg filters that fix it

Phoenix Labs — Thu, 05 Nov 2026 10:38:08 +0000

If you've ever run an old 240p YouTube rip or a 2012 phone video through an AI upscaler, you've probably seen this: the output is bigger and sharper, and somehow looks worse. Faces turn into mosaics. Flat walls grow a grid of tiles. Edges get a crunchy halo.

I build a video restoration app, and this was one of the first quality bugs I had to understand properly. The short version: the upscaler is doing its job. It's sharpening exactly what you gave it, and what you gave it was mostly compression damage.

This post covers what that damage is, how to tell which kind your clip has, and the ffmpeg filters I run before any upscaler touches the video.

Two kinds of old video, two different problems

Most "old video" falls into one of two buckets, and they need opposite treatment.

Tape and DVD (480i / 576i). VHS, Hi8, MiniDV captures and DVDs are usually interlaced: each frame is two half-pictures (fields) captured a fraction of a second apart. On motion you get the comb pattern, thin horizontal stripes on anything moving. There's also analog noise: chroma smear, grain, tracking wobble.

Low-res internet and phone video (≤ 288p, sometimes 360p and 480p). Old uploads, early phone cameras, clips that have been re-shared five times. These are usually progressive, so there's nothing to deinterlace, but they're crushed by compression. The encoder split each frame into 8×8 (or larger) blocks and threw away most of the detail inside each one. What's left is a picture made of tiles.

The mistake I made at first was treating both the same way: a light deinterlace and a gentle denoise, then upscale. On tape that's fine. On a 240p download it's a disaster.

Why the blocks get worse

A neural upscaler is trained to find edges and texture and make them crisp. A block boundary is an edge as far as the model is concerned: a hard, straight, high-contrast line. So it sharpens it.

Upscale a 320×240 clip 4× and every 8×8 block becomes a 32×32 tile with a crisp outline. A gentle tape denoise doesn't help, because it's tuned for random grain and leaves the block grid alone.

You can't fix this afterwards. Once the upscaler has decided the grid is real detail, it's baked into every frame. The fix has to happen before upscaling, while the blocks are still small.

Step 1: find out what you have

ffprobe tells you most of what you need:

ffprobe -v error -select_streams v:0 \
  -show_entries stream=width,height,field_order,codec_name,bit_rate \
  -of default=nw=1 input.mp4

Roughly:

field_order is tt, bb, tb or bt → interlaced. Treat it as tape.
Height is 480, 486 or 576 with no field order reported → probably a tape or DVD capture that lost its metadata. Check a frame with motion for combing.
Height is 288 or less → assume compression blocks, even if it looks "fine" at its native size.

That last rule is the one that matters. At 240p on a phone screen the blocks are barely visible. At 1080p they're the whole picture.

Step 2a: the tape path (deinterlace + light denoise)

For interlaced sources:

ffmpeg -i tape.mp4 \
  -vf "yadif=0:-1:0,hqdn3d=2.0:1.5:3.0:2.5" \
  -c:v libx264 -crf 12 -preset fast -c:a copy \
  tape_clean.mp4

yadif=0:-1:0 deinterlaces to one frame per frame, auto-detects field order, and processes every frame. If you want smoother motion and can afford double the frames, yadif=1 (or bwdif=1) outputs one frame per field instead.
hqdn3d=2.0:1.5:3.0:2.5 is a mild spatial + temporal denoise. The temporal part (the last two numbers) does most of the work on tape grain, because grain changes every frame and the picture doesn't.

Keep the denoise mild. Tape footage that has been denoised hard looks waxy, and an upscaler will happily sharpen wax.

Step 2b: the low-res path (deblock first)

For ≤ 288p progressive sources:

ffmpeg -i lowres.mp4 \
  -vf "spp=5,deblock=filter=strong:block=8,hqdn3d=3.2:2.4:5.5:4.0" \
  -c:v libx264 -crf 12 -preset fast -c:a copy \
  lowres_clean.mp4

Three filters, in this order:

spp=5, simple post-processing. It re-runs the DCT at shifted positions and averages the results, which is very good at removing block artifacts and ringing without blurring real edges much. Quality 5 is slow but worth it at these resolutions; the frames are tiny anyway.
deblock=filter=strong:block=8 smooths what's left along the 8×8 grid specifically.
hqdn3d with stronger settings than the tape path, to clean up the mosquito noise around edges that both of the above leave behind.

Notice there's no yadif. These clips are progressive, and deinterlacing a progressive source just throws away vertical resolution you can't spare.

The result will look softer than the original at native size. That's expected and it's the point: you've removed fake detail (the grid) so the upscaler can work on real detail.

Step 3: keep intermediates lossless

This one cost me more than I'd like to admit. If your pipeline extracts frames, processes them and re-encodes, possibly several times, don't use JPEG for the intermediate frames.

I had frames passing between stages as JPEG to save disk space. Every stage re-compressed them, adding a fresh layer of 8×8 blocks, and the sharpening at the end then brought all of those blocks out. I'd carefully deblocked the source and then put the blocks back myself.

Use PNG. You don't need maximum compression; PNG at level 1 is fast and still lossless:

ffmpeg -i lowres_clean.mp4 -compression_level 1 frames/%06d.png

Same idea for the intermediate video files: -crf 12 (or lower) on the pre-clean output, as above, so you're not adding a new generation of compression before the upscaler sees it.

Step 4: don't throw away pixels to save memory

If you use a heavy model (a diffusion upscaler, for example) on a small GPU, it's tempting to downscale the input a bit more so it fits. Don't do this with a source that's already tiny.

I had a memory fallback that dropped a 320-wide clip to 256 wide before inference. On paper that's a 20% cut. In practice, a 320×240 clip inferred at 256×192 and then stretched to 1080p is about a 5.6× stretch, and it looked pixelated no matter what came after. Shorter processing chunks at the native width were the better trade: slower, but the detail you start with is all the detail you'll ever have.

What to expect

With the right pre-clean, a 240p clip upscaled to 1080p looks like a soft but clean video: real faces instead of mosaics, flat walls that are actually flat. It won't look like it was shot in HD, and nothing honest will make it look that way. The goal is "the best version of what was recorded," not new detail invented by a model.

Tape footage, deinterlaced and lightly denoised, usually scales much better, because a 480i capture has more real information in it than its resolution suggests.

Summary

Check field_order and height with ffprobe before choosing filters.
Interlaced tape/DVD: yadif + mild hqdn3d.
≤ 288p internet/phone video: spp + deblock + stronger hqdn3d, and no deinterlacing.
Deblock before upscaling. You can't remove a grid the upscaler has already sharpened.
Lossless intermediates (PNG, low CRF). Every JPEG generation adds blocks back.
Don't downscale an already-tiny source to save memory.

I use all of this in Phoenix Upscaler, a desktop app that picks the right path for each clip automatically. I wrote more about the two common cases on the site: restoring old phone video and VHS restoration. But the ffmpeg commands above work on their own, in front of any upscaler you like.

If you've found filter settings that work better on a particular kind of source (Hi8, early-2000s webcam, 3GP phone video), I'd like to hear about them in the comments.

Running FlashVSR on an AMD GPU with ROCm (and what broke along the way)

Phoenix Labs — Thu, 05 Nov 2026 08:10:20 +0000

FlashVSR is one of the more interesting video super-resolution models right now. It's a one-step diffusion model built on Wan 2.1, it streams long videos in chunks, and on an NVIDIA card it's fast enough to be practical. I used the FlashVSR-Pro fork, which wraps it in a usable infer.py.

It also has a hard dependency on Block-Sparse-Attention, a CUDA extension. No CUDA, no attention kernel, no model.

I build a video restoration app that has to work on AMD cards too, so I spent a good chunk of August getting FlashVSR running on a Radeon RX 7800 XT (16 GB, RDNA3, gfx1101). It works now. This post is everything I had to change, in the order I hit it, so you don't have to rediscover it.

Setup that finally worked:


GPU	RX 7800 XT, 16 GB
Host	Windows 11 + WSL2, Ubuntu 24.04
ROCm	7.2 system install inside WSL
PyTorch	2.10.0+rocm7.0
Precision	fp16

1. Use WSL2, not native Windows

AMD now ships preview PyTorch wheels for Windows, and they import fine. torch.cuda.is_available() returns True, your card shows up, and you feel great for about six seconds, which is roughly how long a full FlashVSR inference ran before it segfaulted. AMD's own notes mention intermittent crashes during inference on Windows, and that matched what I saw.

The same card inside WSL2 was stable, and a lot faster: a plain fp16 matmul benchmark gave me about 50 TFLOP/s in WSL against about 16 on native Windows.

Getting the GPU visible inside WSL took a few environment variables:

export HSA_ENABLE_DXG_DETECTION=1
export ROCM_PATH=/opt/rocm-7.2.0
export LD_LIBRARY_PATH=/opt/rocm-7.2.0/lib:$LD_LIBRARY_PATH
export HSA_OVERRIDE_GFX_VERSION=11.0.1   # gfx1101; adjust for your card

One non-obvious fix: the PyTorch ROCm wheel bundles its own libhsa-runtime64.so, and that copy didn't detect the GPU through WSL's DXG layer for me. Replacing it with the system ROCm copy (keep a backup) fixed it. If rocminfo sees your card but PyTorch doesn't, check this first.

2. Make Block-Sparse-Attention optional

FlashVSR imports the kernel at the top of diffsynth/models/wan_video_dit.py. Step one is letting it fail:

try:
    from block_sparse_attn import block_sparse_attn_func
    BLOCK_SPARSE_AVAILABLE = True
except ModuleNotFoundError:
    block_sparse_attn_func = None
    BLOCK_SPARSE_AVAILABLE = False

Then, where the attention mask is used, fall back to PyTorch's scaled_dot_product_attention when the kernel isn't there:

if attention_mask is not None and not BLOCK_SPARSE_AVAILABLE:
    q = rearrange(q, "b s (n d) -> b n s d", n=num_heads)
    k = rearrange(k, "b s (n d) -> b n s d", n=num_heads)
    v = rearrange(v, "b s (n d) -> b n s d", n=num_heads)
    x = F.scaled_dot_product_attention(q, k, v)
    x = rearrange(x, "b n s d -> b s (n d)", n=num_heads)

That's dense attention. It ignores FlashVSR's sparse locality mask completely, which costs speed, and more on that below.

3. Turn on AOTriton, or SDPA will eat all your memory

On ROCm, scaled_dot_product_attention only uses a fused flash-attention kernel (AOTriton) on consumer RDNA3 cards if you ask for it:

export TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1

Without it, PyTorch quietly falls back to the math backend, which builds the full attention matrix. For FlashVSR's sequence lengths that's tens of gigabytes. You won't get a helpful error, just an out-of-memory crash, or a process that dies with no traceback at all.

If you only remember one thing from this post, make it this variable.

4. The bug that turned every frame into noise

Dense attention throws away information the model was trained with, so the obvious next step was to keep it. I expanded FlashVSR's block-level sparsity mask into a token-level boolean mask and passed it to SDPA as attn_mask. In theory that gives you the same attention pattern as the CUDA kernel, just slower.

In practice every output frame was pure latent noise. Not slightly wrong, not blurry: static.

The likely culprit is mask polarity (SDPA's boolean attn_mask means "True = attend", and it's very easy to invert the block mask's meaning when expanding it), possibly combined with how the expanded mask interacts with the fused kernel. I didn't fully chase it down, because the plain dense path produced correct, clean output and the masked one wasn't faster on this card anyway: once you hand SDPA an arbitrary mask, you lose most of the fused-kernel advantage.

So the shipped path is dense, and mask expansion stays behind an off-by-default experiment flag. If you try this yourself and get noise, turn the mask off before you start debugging anything else.

5. Memory: ROCm can't defragment, so don't let it fragment

The NVIDIA advice for long diffusion runs is PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. That wasn't available to me on ROCm, and FlashVSR's streaming loop fragments VRAM badly without it. Eventually even a 176 MiB allocation fails on a card with gigabytes "free".

Three patches fixed it.

Offload the DiT before decoding. FlashVSR's TCDecoder runs after the diffusion step in each chunk, with the DiT still resident. Moving it off first gives the decoder room:

self.load_models_to_device([])
torch.cuda.empty_cache()
cur_frames = self.TCDecoder.decode_video(...)
self.load_models_to_device(['dit'])

Stream decoded frames to the CPU. The decoder accumulates finished frames on the GPU and stacks them at the end. At 1280×960 that's around 3 GB of extra residency, scattered across the heap. Moving each finished frame to host memory as it's produced keeps the GPU heap compact:

out.append(xt.to("cpu", non_blocking=False))

Clean up after every streaming segment. Delete the per-segment tensors and empty the cache before the next DiT step, so the allocator can hand back contiguous blocks:

del cur_frames, cur_latents, noise_pred_posi, cur_LQ_frame
gc.collect()
torch.cuda.empty_cache()

None of these change the output. They just stop the run from dying halfway through.

6. Pick a resolution the card can actually do

With all of the above, 16 GB comfortably handles 2× upscaling from an input around 320 to 384 pixels wide. A 512-wide input ran one streaming step and then died without a traceback. Some other knobs I tried:

fp16 over bf16. bf16 was less reliable on RDNA3 in my runs.
DiT tiling (tile_dit) fits larger inputs into memory, but was about 8× slower. I only use it as a last resort.
For low-res sources, keep the native width. For a 320×240 clip, I found it better to shorten the chunks (2 s down to 1 s) than to downscale to 256 wide first. Downscaling a source that small throws away detail you can't get back.

7. Don't trust WSL's idea of how much RAM you have

Inside WSL, psutil reports the VM's memory cap, not the machine's. On a 32 GB host, WSL showed about 10 GB, and my memory-tuning code treated it as a small machine. It reloaded the model every two chunks to be safe, which roughly doubled the run time.

Two fixes:

Raise the VM limit in %UserProfile%\.wslconfig (memory=12GB on a 32 GB host), then run wsl --shutdown once.
Pass the real host RAM in from the Windows side as an environment variable, and size things from that.

Keeping one model process warm across chunks, and restarting it every 12 or so instead of every 2, was the single biggest speedup after getting attention right.

How fast is it?

My first working run took about 230 seconds for 2 seconds of 384×384 video upscaled to 768×768. After the memory and warm-worker fixes, a realistic number on the 7800 XT is about a minute of processing per second of 320 to 360p source.

That's fine for clips and highlights. A full 2-hour tape is not a reasonable job for this card, and dense attention is the reason. NVIDIA cards with the real sparse kernel are much faster.

The quality catch: diffusion warps on motion

Getting FlashVSR to run is half the story. On real footage, especially fast motion like a kick or a head turn, pure FlashVSR output tends to warp: edges drift a few pixels from where they are in the source, and faces can subtly change shape between frames.

What worked better for me was using it as a detail donor rather than the final picture:

Run a conventional super-resolution model (Real-ESRGAN class) on the source. It's less detailed, but its geometry stays put.
Run FlashVSR and line its output up with that base.
Take only the high-frequency detail from FlashVSR, and only where the two agree at low frequency. Where they disagree (the warp), fall back to the base.
Smooth that detail layer over time a little, so it doesn't shimmer.

The result keeps FlashVSR's texture and the source's shape. It also gets rid of the bright "sticker outline" that shows up around moving people when you sharpen a slightly misaligned diffusion output.

Summary

If you want FlashVSR on an AMD card:

Use WSL2 with a system ROCm install, and swap in the system libhsa-runtime64.so if PyTorch can't see the GPU.
Make Block-Sparse-Attention optional and fall back to dense SDPA.
Set TORCH_ROCM_AOTRITON_ENABLE_EXPERIMENTAL=1.
Don't pass an expanded sparsity mask to SDPA unless you enjoy static.
Offload the DiT before decoding, move decoded frames to the CPU, and clean up after every segment.
Stay around 320 to 384 px input width on 16 GB, in fp16.
Tell your code the real host RAM, not WSL's.

I packaged all of this into Phoenix Upscaler, a desktop app for restoring old video (tapes, DVDs, early phone footage), where the AMD generative mode sets up WSL and ROCm for you. The setup guide covers what it installs, and there's a longer write-up on restoring old video in general. But everything above works on a plain FlashVSR-Pro checkout too.

If you get it running on a different RDNA card (a 7900 XTX, or anything RDNA2), I'd like to hear what resolution it handles.