[PROPOSAL] The C-vs-Rust dual-build comparison from #2207 never runs; the C-only build drops 708 and HEVC captions
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 领域
- ci-cd, testing-qa
调研方向
Start by reading #2207, #2109, and the sample-platform wiring at mod_ci/controllers.py:264-268; compare those with this repository’s GitHub Actions workflows. The proposal calls for running both Linux builds against a small public sample set, reporting output differences without blocking CI, then triaging each difference. The issue asks maintainers to decide where the job and samples should live, so the implementation scope depends on that decision.
由索引模型根据 Issue 内容生成。
描述
#2207 added two builds so that "both must produce identical output on the sample platform; divergence means a Rust port introduced a behavioral difference". That comparison never got wired up: sample-platform#1122 pointed the platform at the "(with migrations)" builds only (mod_ci/controllers.py:264-268), and no workflow compares the two artifacts. In #2109 you mentioned Rust ports won't be merged until this kind of C-vs-Rust check exists.
I built both variants from master on macOS (same source, only -DDISABLE_RUST differs) and compared them on public samples from https://streams.videolan.org/streams/ts/ with 5 option sets each:
| Sample | Result |
|---|---|
Closed Caption EIA.ts |
identical |
atsc-cea-708-dtvcc-and-cea-608.ts (first 20 MB) |
608 identical; the min-rust build writes no 708 file (Rust: 5 cues), both exit 0 |
CC/wabc-4pm-ota.clip1.ts (US broadcast) |
608 identical (40 cues); the min-rust build writes no 708 file (Rust: 42 cues), both exit 0 |
CC/hevc_cc.ts |
min-rust build writes nothing (exit 10) although it logs "Total caption blocks received: 762"; Rust extracts 608 + 708 |
I'd like to build the comparison:
- A CI job that runs both Linux artifacts on a small public sample set and reports differences (non-blocking at first).
- Triage each difference (fix the C path, or record it as expected).
- Then use it as the check for Rust ports.
Two questions before I start:
- Should this live in this repo's GitHub Actions, or in the sample platform?
- Where should the samples come from (download from VideoLAN with caching, or the sample platform)?
- 主要语言
- C
- 星标
- 908
- 派生
- 595
- 平均合并
- 3 天 6 小时
- 30 天内合并 PR
- 31
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
CCExtractor/ccextractor 的其他 Issue
-
[BUG] Heap buffer overflow in parse_PMT with C0/C1 section length可能已有人在做 @kun-codes 于 2 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
CCExtractor/ccextractor#2419 ·
维护者通常 1 天内回复
-
[BUG] Filename sequence expansion (`+`) panics on numeric values exceeding `i32::MAX`可能已有人在做 @muntasir-396 于 5 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
CCExtractor/ccextractor#2402 ·
维护者通常 1 天内回复
-
CCExtractor/ccextractor#2425 ·
维护者通常 1 天内回复
-
[PROPOSAL] Port the MythTV packet reader (myth.c) to Rust可能已有人在做 @kaihere14 于 2 天前认领。 未关闭
难度 5/5 一周以上 新手友好度 25/100
CCExtractor/ccextractor#2421 ·
维护者通常 1 天内回复
-
CCExtractor: stack out-of-bounds write and quadratic out-of-bounds read in the DVB subtitle descriptor parser (parse_dvb_description)可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 4/5 3-5 天 新手友好度 48/100
CCExtractor/ccextractor#2417 ·
维护者通常 1 天内回复
查看 CCExtractor/ccextractor 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
libsdl-org/SDL#16584 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 63/100
FriendsofECCE/ECCE#519 · 2 条评论 ·
-
难度 1/5 1 小时以内 新手友好度 95/100
containers/crun#2415 ·
维护者通常 1 天内回复