Eyevinn / go-608
84%
main: 84%

LAST BUILD BRANCH: release/v0.8.0
DEFAULT BRANCH: main
Repo Added
Files 35
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH fix/decoder-incremental-feed
branch: fix/decoder-incremental-feed
CHANGE BRANCH
x

coverage: 84.207% (+0.3%) from 83.897%
30569401928

Pull #69

github

tobbee 
fix(cta608): carry Decoder parse state across Feed calls

A Decoder fed one byte pair at a time decoded differently from one fed a whole
buffer. Every timed path feeds pair-by-pair -- that is what preserves per-frame
timing -- so this reached go608-extract, go608-info, and any consumer decoding
an mp4 or SCC frame by frame. Two 608 constructs straddle a pair boundary and
both were corrupted:

  - Extended characters lost their backspace-and-replace. An extended char is
    transmitted as a fallback char pair followed by the two-byte extended code,
    so in the timed path the two always land in different Feed calls and the
    backspace had nothing pending to remove. "CAFÉ ÀU LAIT" decoded as
    "CAFEÉ AÀU LAIT". This affects every mode, pop-on included, so any accented
    letter or curly quote in an mp4/SCC -> WebVTT conversion was wrong.

  - Doubled control codes were not collapsed across the boundary. Harmless for
    pop-on, where a second EOC/EDM/ENM is idempotent on the displayed screen,
    but a doubled roll-up CR scrolled twice and dropped a line: a 3-row roll-up
    decoded as r13="BBB", r14="", r15="CCC" instead of AAA/BBB/CCC.

Parse's collapse state lived in a parser value created fresh per call. Parse is
now a thin wrapper that still does exactly that -- so whole-buffer parsing and
Parse-then-Push callers are unchanged -- while Decoder owns one parser for its
lifetime. The extended-char case additionally needs the receiver to undo a
character it has already displayed, so parse now emits an explicit BS when the
fallback is no longer pending; that is CTA-608-E's backspace-and-replace as
described on the wire, not a workaround.

The internal/convert comment predicted the roll-up half of this and reasoned it
was harmless because go-608's own encode paths are pop-on. True for content
go-608 generates, but not for the third-party roll-up input go608-extract
exists to read; corrected.
Pull Request #69: cta608: carry Decoder parse state across Feed calls

18 of 18 new or added lines in 2 files covered. (100.0%)

3375 of 4008 relevant lines covered (84.21%)

0.97 hits per line

Relevant lines Covered
4008 RELEVANT LINES 3375 COVERED LINES
0.97 HITS PER LINE
Source Files on fix/decoder-incremental-feed

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
30569401928 fix/decoder-incremental-feed fix(cta608): carry Decoder parse state across Feed calls A Decoder fed one byte pair at a time decoded differently from one fed a whole buffer. Every timed path feeds pair-by-pair -- that is what preserves per-frame timing -- so this reached go60... Pull #69 tobbee github
84.21
See All Builds (45)