Skip to content

Fix 40ms gap in rolling teletext subtitles - #2292

Open
alaotach wants to merge 1 commit into
CCExtractor:masterfrom
alaotach:fix-teletext-webvtt-gap
Open

Fix 40ms gap in rolling teletext subtitles#2292
alaotach wants to merge 1 commit into
CCExtractor:masterfrom
alaotach:fix-teletext-webvtt-gap

Conversation

@alaotach

@alaotach alaotach commented Jul 8, 2026

Copy link
Copy Markdown

[FIX] Remove 40ms hide timestamp contraction in telxcc causing rolling subtitle blink

In raising this pull request, I confirm the following (please check boxes):

Reason for this PR:

  • This PR adds new functionality.
  • This PR fixes a bug that I have personally experienced or that a real user has reported and for which a sample exists.
  • This PR is porting code from C to Rust.

Sanity check:

  • I have read and understood the contributors guide.
  • I have checked that another pull request for this purpose does not exist.
  • If the PR adds new functionality, I've added it to the changelog. If it's just a bug fix, I have NOT added it to the changelog.
  • I am NOT adding new C code unless it's to fix an existing, reproducible bug.

Fixes

Closes #2288

Problem

When converting DVB teletext subtitles to WebVTT, rolling/scrolling subtitles that update every ~40ms produce a visible blink or flash between cues in players such as Infuse.

The root cause is in src/lib_ccx/telxcc.c. The telxcc component hardcodes a 40ms contraction on every subtitle hide timestamp:

// it would be nice, if subtitle hides on previous video frame, so we contract 40 ms (1 frame @25 fps)
ctx->page_buffer.hide_timestamp = timestamp - 40;

This was originally intended to hide a subtitle one video frame early on 25fps content. However, the WebVTT exporter independently subtracts 1ms from end timestamps to prevent adjacent cues from sharing the same boundary timestamp. The two reductions combine, producing a ~41ms gap between consecutive rolling teletext cues.

For rolling teletext that updates every ~40ms, this gap is effectively the same duration as a full cue, so compliant players interpret it as the subtitle completely disappearing before the next one appears causing the blink.

Two additional problems with the original approach:

  • The 40ms figure is only correct for 25fps. It is already wrong for 24fps (41.7ms/frame) and 30fps (33ms/frame).
  • Frame-timing logic does not belong in the teletext parser layer; it belongs in a frame-aware encoder.

Fix

Remove the 40ms contraction in telxcc.c and let the WebVTT exporter's existing 1ms gap handle overlap prevention on its own. The 1ms gap is spec-compliant and imperceptible.

// We no longer contract 40ms here. The WebVTT exporter already subtracts 1ms
// to prevent adjacent cues from sharing a boundary timestamp, which is sufficient.
// The previous 40ms contraction (1 frame @ 25fps) caused a visible ~41ms blink gap
// in rolling teletext subtitles on spec-compliant players (e.g. Infuse).
// It was also incorrect for non-25fps content.
ctx->page_buffer.hide_timestamp = timestamp;

Repro Instructions

  1. Take any DVB teletext stream containing rolling/scrolling subtitles (sample attached in issue DVB_TELETEXT to WEBVTT rolling issue. #2288).
  2. Convert to WebVTT using CCExtractor: 
    ccextractor input.ts -o output.vtt
  3. Open the output in a player that renders WebVTT strictly.
  4. Before fix: a visible ~40ms blink is present between each rolling cue update.
  5. After fix: subtitle rolls smoothly with no blink.

The gap is also directly visible in the raw WebVTT output consecutive cues have a ~40ms hole between the end of one timestamp and the start of the next instead of being contiguous.

@ccextractor-bot

ccextractor-bot commented Jul 8, 2026

Copy link
Copy Markdown
Collaborator
CCExtractor CI platform finished running the test files on linux. Below is a summary of the test results, when compared to test for commit 2feb09a...:
Report Name Tests Passed
Broken 0/13
CEA-708 1/14
DVB 0/7
DVD 0/3
DVR-MS 0/2
General 0/27
Hardsubx 1/1
Hauppage 0/3
MP4 0/3
NoCC 10/10
Options 0/86
Teletext 0/21
WTV 0/13
XDS 0/34

Your PR breaks these cases:

NOTE: The following tests have been failing on the master branch as well as the PR:


It seems that not all tests were passed completely. This is an indication that the output of some files is not as expected (but might be according to you).

Check the result page for more info.

@alaotach

alaotach commented Jul 8, 2026

Copy link
Copy Markdown
Author

the test failure is a CI infra 504 timeout, not related to the change so can any maintainer re-trigger the test

@cfsmp3

cfsmp3 commented Jul 26, 2026

Copy link
Copy Markdown
Contributor

Claude review, but I've reviewed the review

First, ignore the CI run — it's invalid. The per-category results are:

Options 0/86 XDS 0/34 General 0/27 WTV 0/13 CEA-708 1/14
DVB 0/7 DVD 0/3 DVR-MS 0/2 Teletext 0/21 MP4 0/3
NoCC 10/10 Hardsubx 1/1

A change inside process_telx_packet cannot possibly affect DVD, XDS, WTV or
DVR-MS samples. Everything failing except NoCC is what you'd see if the binary
produced no output at all. I verified locally: sample 121 (.dvdraw), which
alone accounts for 58 of the 197 flagged tests, is byte-identical between master
and this branch on all four of its commands, as are three other non-teletext
samples I checked. The run needs redoing; don't chase those failures.

Your change fixes a bug you didn't mention. On master, teletext pages that
are displayed for exactly 40 ms collapse into zero-duration cues:

master: 00:00:00.997 --> 00:00:00.997 <- start == end
00:00:01.377 --> 00:00:01.377

this PR: 00:00:00.997 --> 00:00:01.037
00:00:01.037 --> 00:00:01.377

Counted across the teletext samples I have locally:

sample cues zero-length (master) zero-length (PR)
27d7a43dd6 210 87 0
8c1615c1a8 26 8 0
7e4ebf7fd7 28 5 0
dcada745de 232 3 0

Every zero-length cue disappears. That's very likely a large part of the blink
being reported in #2288, and it's worth putting in the description.

But the reasoning in the description is wrong. You state that the WebVTT
exporter already subtracts 1 ms, so the two reductions combine into a ~41 ms gap.
Measured on real samples, the master gap is exactly 40 ms and this branch
produces exactly 0 ms. The -1 at ccx_encoders_webvtt.c:132, :323 and
:452 is not on the teletext path — line 356 calls
write_stringz_as_webvtt(sub->data, context, sub->start_time, sub->end_time)
with no subtraction at all. So the result is adjacent cues that share a
boundary timestamp, not cues separated by 1 ms.

That's likely harmless (WebVTT allows touching cues, and it's what makes rolling
look continuous), but it isn't what the comment in your patch says is happening.
I'd rather the code and the comment agree. Simplest fix:

ctx->page_buffer.hide_timestamp = timestamp - 1;

That gives the 1 ms separation you describe, still eliminates every zero-length
cue, and still removes the blink. If you'd rather keep touching boundaries,
that's defensible too — just say so explicitly and drop the claim about the
exporter's 1 ms.

Dead code: with hide_timestamp = timestamp, the guard immediately below can
never fire:

if (ctx->page_buffer.hide_timestamp > timestamp)
{
    ctx->page_buffer.hide_timestamp = 0;
}

It was there to catch the unsigned underflow of timestamp - 40. Please remove
it, or keep it if you go with - 1, where it still guards timestamp == 0.

Unrelated to this PR, but I hit it while testing: 85c7fc1ad7…mpg and
f1422b8bfe…ts both segfault on --out=webvtt, identically on master and on
this branch. Not your problem — I'll open a separate ticket.

Please push the above and re-run CI.

@cfsmp3
cfsmp3 self-requested a review July 26, 2026 20:14
cfsmp3
cfsmp3 requested changes Jul 26, 2026
View reviewed changes

@cfsmp3 cfsmp3 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See previous comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cfsmp3 cfsmp3 cfsmp3 requested changes

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

DVB_TELETEXT to WEBVTT rolling issue.

3 participants

@alaotach @ccextractor-bot @cfsmp3