DEV Community: tian song

I measured burned-in subtitle removal with PSNR. The failures are the interesting part.

tian song — Wed, 04 Nov 2026 08:27:09 +0000

Most "remove burned-in subtitles" tutorials end at a before/after. The after always looks fine as a thumbnail. The useful question is what "fine" means numerically, and almost nobody answers it.

I spent a while on this, so I measured it. Here is the method, the numbers, and the two clips where it goes wrong.

The setup

PSNR needs a reference. So use clips where you can produce both versions: same camera, same encoder settings, one with text burned in, one without. Then you compare your output against the clean plate instead of against your memory of it.

ffmpeg -i clean.mp4 -i output.mp4 -lavfi psnr -f null -

Two caveats before the numbers.

PSNR is per-pixel and per-frame. It cannot see temporal crawl, which is the artifact people actually notice on subtitle removal. A method can score well and still shimmer when you pause it. PSNR is a lower bound on quality, not a verdict.

The ceiling matters more than the score. Re-encode the clean clip and compare it to itself, and you get the best number reachable at those settings. Mine was 37.4 dB. A 28 dB result against a 37.4 dB ceiling is a much better outcome than 28 dB sounds on its own.

Results

clip	PSNR	what's in frame
clean re-encode (ceiling)	37.4 dB	reference
street, slow pan	28.3 dB	text over a moving background
crowd, text crossing faces	19.8 dB	people moving under the text
vertical, drifting text	20.5 dB	1080x1920, karaoke-style motion

Same clips, naive baselines:

method	PSNR
`ffmpeg` delogo	16.8 dB
box blur over the region	18.0 dB
feeding the subtitled clip back in as "output"	8.8 dB

That last row is not a joke, it is the floor. It tells you how much of any score is just the text still being there.

Both naive methods land below the crowd clip that everyone would call a failure. That is the honest summary of covering text instead of rebuilding it: you are not removing anything, you are smearing it, and the metric says so.

Why the crowd clip collapses

Text over faces fails for a specific reason. The text occupies the same pixels across many frames, so there is no clean frame to borrow the background from. The information was never recorded. Whatever fills that hole is invented, not recovered.

Then the content compounds it. What has to be reconstructed is skin and hair with fine structure, and any residual smearing reads as wrong instantly, because we are tuned to faces. On the street clip the background is a wall. A slightly soft wall is still a wall. A slightly soft cheek is a mistake.

The vertical clip fails differently. The mask moves with the text, so the region that needs rebuilding changes every frame and nothing can be amortised across the clip. Static subtitles are the easy case, and most subtitles are not static.

What PSNR does not tell you

Temporal consistency. The main reason a good-scoring result still looks bad.
How it holds up at 2x on a phone screen, which is where most of this content is watched.
Anything about audio, obviously.

And one bias worth knowing: PSNR rewards blur. A soft reconstruction of a textured region often scores higher than a sharp one with slightly wrong structure. So the metric leans toward exactly the failure mode people complain about. If you optimise against PSNR alone you will ship something that scores well and looks like vaseline.

Reproducing it

Disclosure: I build one of these tools, so treat the numbers as coming from an interested party. That is precisely why the clips and the exact commands are public, including the failures:

Benchmark repo with the clips and commands: github.com/vaughnn/burned-in-subtitle-removal-benchmark
The tool I work on: videotextremove.com

If you have a clip I did not test, run the two commands above against your own clean plate. It takes about a minute and it will tell you more than any comparison table, including mine.

Reading a 40,000-comment YouTube thread with the Data API

tian song — Fri, 09 Oct 2026 06:19:23 +0000

Most tutorials that show you how to read YouTube comments stop at the
first page. Here is what actually happens when you try to read a thread
that has 40,000 of them.

The endpoint, and what it actually costs

Comments live behind commentThreads.list on the YouTube Data API v3:

GET https://www.googleapis.com/youtube/v3/commentThreads
    ?part=snippet,replies
    &videoId=VIDEO_ID
    &maxResults=100
    &pageToken=NEXT_PAGE
    &key=YOUR_API_KEY

Two things bite people here.

It is quota-metered, not rate-limited. commentThreads.list costs 1 unit
per call against a default 10,000-unit daily quota. At maxResults=100 that
is 100 calls — and 100 calls is 1% of your day. A busy video with 40,000
comments needs 400 calls. You will hit the ceiling faster than you expect,
and the error is a plain 403 quotaExceeded, not a retryable 429.

maxResults is capped at 100 and the cap is silent. Ask for 500 and you
get 100 with no warning. Loop until a page returns fewer items than you asked
for, or you will spin forever on a video whose comment count is a multiple
of 100.

Pagination that actually terminates

The naive loop breaks in three places: the last page, a video with comments
disabled, and a video that is age-restricted.

import requests

def read_thread(video_id: str, api_key: str):
    url = "https://www.googleapis.com/youtube/v3/commentThreads"
    token, seen = None, 0

    while True:
        params = {
            "part": "snippet,replies",
            "videoId": video_id,
            "maxResults": 100,
            "key": api_key,
        }
        if token:
            params["pageToken"] = token

        resp = requests.get(url, params=params, timeout=15)

        # 403 covers both "comments disabled" and "quota exhausted".
        # Read the reason, do not just retry.
        if resp.status_code == 403:
            reason = resp.json()["error"]["errors"][0]["reason"]
            if reason == "commentsDisabled":
                return seen
            raise RuntimeError(f"quota or permission problem: {reason}")

        payload = resp.json()
        items = payload.get("items", [])
        seen += len(items)

        token = payload.get("nextPageToken")
        if not token:
            return seen

The nextPageToken is absent on the final page — that is your exit
condition. Do not compare against pageInfo.totalResults; it is an estimate
and it drifts on large threads.

Replies are a second request

commentThreads.list returns the top-level comment plus, by default, a
single reply. Getting the rest means calling comments.list with
parentId. On a thread with heavy back-and-forth this doubles or triples
your quota spend, and there is no way to know in advance how much.

If you only need the top-level conversation, do not request replies at all —
you get roughly 3x the coverage for the same quota.

When you do not want to write any of this

I built Apriocity because I kept writing this same
pagination loop for one-off research tasks. It does the paging, the quota
accounting and the reply expansion for you, and hands back CSV or JSON:

paste a video link, read the whole thread, search it by keyword
export the slice as CSV or JSON
batch mode: up to ten videos, one ZIP back

It uses the same public API described above, so what you see is exactly
what is publicly visible — nothing is stored on the server side.

The short version

commentThreads.list = 1 quota unit per call, maxResults capped at 100
nextPageToken missing = done; do not trust totalResults
403 is overloaded: check the reason field before retrying
Replies cost extra calls — skip them unless you need them

If you are doing this once, the API is fine. If you are doing it weekly,
that loop is worth automating away.