DEV Community: 강명석

Four places ffmpeg.wasm fails silently in a Next.js app (and the fixes)

강명석 — Fri, 21 Aug 2026 18:45:35 +0000

I shipped four browser-only video tools with ffmpeg.wasm: trim, compress, video-to-GIF and MP3 extraction. Files never leave the browser, nothing to install.

Trim · Compress · GIF · MP3 (Korean UI, but the buttons are obvious)

Getting there, I hit four walls. Every one of them surfaced as a single "conversion failed" line in the UI and nothing in the console. Writing them down for the next person. Stack: Next.js App Router + webpack, @ffmpeg/ffmpeg 0.12, self-hosted core.

1. webpack hijacks the dynamic import inside the worker

@ffmpeg/ffmpeg spawns its worker like this:

new Worker(new URL("./worker.js", import.meta.url), { type: "module" });

webpack recognises the pattern and bundles the worker. Fine. But it also rewrites the import(coreURL) inside that worker to go through its own module loader. The core URL arrives at runtime as a blob: URL, which webpack's loader has never heard of, so it dies with Cannot find module 'blob:...'. The error is thrown inside the worker, so the main-thread console stays empty.

Fix: keep the worker out of the bundle. Copy node_modules/@ffmpeg/ffmpeg/dist/esm/worker.js to public/ffmpeg/<version>/lib/ and pass it via classWorkerURL in load(). Now the untouched worker runs.

2. classWorkerURL needs the origin

Passing a path like /ffmpeg/0.12.x/lib/worker.js is not enough. The library resolves it with new URL(classWorkerURL, import.meta.url), and inside the bundle import.meta.url is a build-time file:///C:/... path. So it goes looking for file:///C:/ffmpeg/... and fails.

const BASE = `/ffmpeg/${FFMPEG_VERSION}`;
await ffmpeg.load({
  coreURL: `${location.origin}${BASE}/core/ffmpeg-core.js`,
  wasmURL: `${location.origin}${BASE}/core/ffmpeg-core.wasm`,
  classWorkerURL: `${location.origin}${BASE}/lib/worker.js`,
});

Prefix location.origin and it works.

3. You cannot build a GIF palette with -vf

For decent GIF quality you run palettegen first and paletteuse second. Doing it in one pass needs split to fork the stream, and a filter graph with two outputs is something -vf cannot take. It fails silently.

# does not work
-vf "fps=12,scale=480:-1,split[a][b];[a]palettegen[p];[b][p]paletteuse"

# works
-filter_complex "[0:v]fps=12,scale=480:-1,split[a][b];[a]palettegen[p];[b][p]paletteuse"

Switch to -filter_complex and label the input [0:v].

4. Permissions-Policy: display-capture

This one is from the screen-recorder next door. The security headers had display-capture=(). With that, getDisplayMedia() rejects immediately without showing the permission prompt. To the user it looks like the button does nothing. It has to be display-capture=(self). Same story for camera and microphone.

Bonus: there is no denominator for the progress bar

The core wasm is 30+ MB. Over compressed transfer there is no Content-Length, so you have nothing to divide by. I keep the uncompressed wasm size as a constant and use that. The byte count you read from fetch is post-decompression, so the units match. Actual transfer is about 9.8 MB gzip, 8 MB brotli.

Testing with a canvas-generated video

Tools that need a file are awkward to test automatically. A canvas that changes background colour every second, recorded with captureStream() + MediaRecorder into a 6-second clip and injected via DataTransfer, turns out to be enough. Trim is verified by reading pixel colours from the output (cut 2–4 s, first frame green, last frame blue). GIFs are verified by counting 21 F9 04 (frames) and 21 FF 0B (loop block) in the bytes. One gotcha: requestAnimationFrame pauses in background tabs, so draw with setInterval.

Everything is live. If a file fails, tell me the format.

https://toolnjoy.com/video-trim
https://toolnjoy.com/video-to-gif
Other tools on the site: https://toolnjoy.com

A rule-based Korean dialect converter with no LLM: eight guards that keep standard Korean intact

강명석 — Fri, 21 Aug 2026 18:40:22 +0000

I built a Korean dialect converter that runs entirely in the browser and uses no LLM. Type a standard Korean sentence and it rewrites it the way people speak in Gyeongsang, Jeolla, Chungcheong, Gangwon or Jeju. Paste a dialect sentence and it converts back to standard Korean. Nothing leaves the browser.

Try it: https://toolnjoy.com/dialect-converter (Korean UI)

The hard part was not producing dialect. It was not breaking standard Korean. Every time I widened a rule, a perfectly normal sentence got mangled somewhere. Here is what I ended up with. Most of it applies to any rule-based text rewriter (honorific converters, profanity filters, spelling normalizers).

Shape of the thing

Four modules:

file	job
core	sentence splitting, sentence-type detection, ending replacement
endings	per-region ending tables (declarative / interrogative / propositive / imperative × politeness)
words	per-region vocabulary
reverse	dialect → standard

Forward conversion goes "decide the sentence type, then pick the region's ending". Reverse goes the other way: "look at the ending, infer the sentence type". You cannot just invert the forward table, so reverse has its own table. Each reverse rule carries a type, which removes the detection step entirely.

In reverse mode the user does not pick a region. I run all five and keep the one with the highest score (4 points per matching ending + syllable count of matched words). People who paste dialect usually do not know which region it is from. That is why they came.

Eight guards, each from a real failure

1. Never reverse a form that appears on the standard side of any table. The Gyeongsang table had 함께 → 같이 (together). Reverse flipped it and rewrote "같이 보게" into "함께 보게", except 같이 is perfectly standard. Fix: anything that ever appears in a standard column anywhere is excluded from reverse candidates.

2. Question endings only count when there is a question mark or a wh-word. Gyeongsang -나 / -노 mark questions. But 하나 ("one") also ends in -나. Without the guard, "하나 주세요" (give me one) became "하니 주세요".

3. Count the prefix in words, not in the sentence. In "왜 그랴?" the ending 그랴 has a one-character stem. Counted at sentence level it looked like two characters ("왜 그") and passed a minimum-length check it should have failed.

4. Leave single characters alone. I added the particle 와 as vocabulary and "PDF와 이미지" became "PDF왜 이미지". Particles attach to Latin letters and digits too, and a single character gives you no boundary to anchor on. Only two single-character entries survived, both nouns.

5. Nouns matched mid-word. 벼락 (lightning) became 나락락 because 벼 → 나락 (rice plant) matched inside it. Same story for 오이소박이, 부담, 벽지. Noun entries get a marker and their own boundary check.

6. Single-character particles punch through boundaries. 도 was in the particle list, so 가재도구 (household goods) was split as 가재 + 도. Rule: if more Hangul follows a one-character particle, it is not a particle. Also, particles must agree with the final consonant: the 이 in 가재이 cannot be a subject particle because 가재 has no final consonant (it would need 가). That single check stopped the propositive 가재이 from turning into 까재이.

7. -으니까 is not a sentence end. Treating 니까 as a terminal ending turned "왔으니까 드세요" (since you came, please eat) into a question-then-imperative in Gyeongsang. 니까 terminates only after a ㅂ final.

8. Greetings before endings. If the ending rule hits 감사합니다 first you get 감사합니더 and the real Gyeongsang 고맙심더 never appears. Vocabulary of four or more characters is applied before endings. Four, because anything shorter at the end of a sentence would swallow the ending and the ending rule would never fire.

The biggest hole was punctuation

All my test sentences had periods. A real user typed "안녕하세요 저는 백수입니다 돈을 주세요" with none, and not a single character changed. The whole thing was one sentence so only the last ending matched.

Now sentences split on polite terminal endings followed by whitespace (습니다, 세요, 어요…). Casual one-character endings (-다, -어) are deliberately not in the list: in "이거 다 먹어" the 다 would become a sentence end.

Using the whole repository as a regression corpus

This tool never throws. It produces quietly wrong output. So the only safety net is a corpus check: scrape every Korean string literal and every JSX prose node from the codebase (about 9,400 snippets, all assumed to be standard Korean), run reverse over all of them, and assert that not one character changes. Every rule widening gets caught here. Jeju -게, Chungcheong -유, Gyeongsang -니라 were all caught this way.

Scraping only string literals misses things. "오직 → 오죽" only showed up in JSX prose.

Importing 8,886 dialect headwords from the national dictionary

I widened the reverse vocabulary with the National Institute of Korean Language's open dictionary (Urimalsaem). You cannot import it blindly: many dialect forms are homographs of standard words.

패기: 覇氣 (spirit) in standard Korean, "hiccup" in one dialect
새똥: bird droppings, or "dawn"
영신: a given name, listed as "shaman"

A corpus filter cannot catch these because 패기 does not appear in my codebase. So the import is two-layered:

rewrite layer: exactly one standard equivalent, and the dictionary API confirms there is no non-dialect sense
annotate layer: text untouched, the meaning is only listed ("this word also means X in region Y")

Two-syllable homographs were the danger zone. I first demoted every two-syllable entry, then queried the dictionary API for 7,766 headwords asking "does a standard sense exist", which restored 1,340 of them. Two things the dictionary cannot catch: personal names (handled with a name list) and real-world text (I ran 890k Korean sentences through reverse and dropped any entry that changed even one character).

Still weak

Jeju changes both endings and vocabulary, so a round trip (standard → Jeju → standard) does not return the original
Jeju propositive -게 (먹게 = let's eat) is identical to standard -게, so it is not in. Adding it turns 유일하게 (uniquely) into 유일하자
Splitting only looks at polite endings and ㅆ past-tense forms; "이거 다 먹어 그리고 자" is still one sentence

Everything above came from actually using the thing, not from the test suite. If you read Korean and get a weird result, tell me the sentence.

Converter: https://toolnjoy.com/dialect-converter
Regional pages: Gyeongsang · Jeolla · Chungcheong · Gangwon · Jeju
Dictionary lookup only: https://toolnjoy.com/dialect-dictionary