[BUG] CEA-708 .srt is written as Latin-1 and ignores --utf8/--latin1/--unicode
メンテナーはふだん 2 日以内に返信
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 65/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
調査の方向性
Start by reading src/rust/src/decoder/output.rs and the C writer ccx_decoders_708_output.c, then trace how global encoding flags reach the 608 writer and the 708 writer. Test a CEA-708 stream containing accented G1 characters with default settings and --utf8, --latin1, and --unicode; done means 708 output follows the selected encoding, with UTF-8 as the documented default.
索引モデルが issue の本文から書いたものです。
説明
CCExtractor version: 0.96.6 release AppImage (--version prints 0.96.5, commit 185631dc). The code below is unchanged on master (d7eb132).
Necessary information
- Is this a regression (i.e. did it work before)? Don't know
- What platform did you use? Linux
- What were the used arguments?
-o out.srt(same result with--service 1)
Additional information
The CEA-708 .srt is written as raw Latin-1 bytes, while --help says UTF-8 is the default ("--utf8: Encode subtitles in UTF-8 (no longer needed because UTF-8 is now the default)"). --utf8, --latin1 and --unicode don't change the 708 file at all.
On an MXF with 608 and 708 captions in Portuguese, one run gives a UTF-8 608 file and a Latin-1 708 file:
$ ccextractor in.mxf -o out.srt
$ file out.srt out.p0.svc01.srt
out.srt: Unicode text, UTF-8 text, with CRLF line terminators
out.p0.svc01.srt: ISO-8859 text, with CRLF line terminators
"você" in the 708 file is 76 6f 63 ea, the same with no flag, --utf8, --latin1 or --unicode. Only a per-service charset gives UTF-8: --service "1[ISO-8859-1]" writes 76 6f 63 c3 aa.
From the code, the 708 writer never looks at the global encoding. With no service charset there is no iconv descriptor, and write_char in src/rust/src/decoder/output.rs (and the C writer in ccx_decoders_708_output.c) writes the internal symbol bytes as they are, so G1 characters come out as their Latin-1 byte. I expected the 708 output to follow --utf8/--latin1/--unicode like the 608 output does, with UTF-8 as the default.
The input is a 395 KB MXF that I can share if it helps. Any 708 stream with G1 characters (accented letters) should show the same thing.
- 主要言語
- C
- スター
- 913
- フォーク
- 603
- 平均マージ
- 1日 10時間
- マージ済み PR（30日）
- 24
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
CCExtractor/ccextractor のほかの issue
-
[Security] Heap buffer overflow (OOB read past GPAC sample buffer) in process_avc_sample() at mp4.c:99 when parsing a crafted MP4 file対応中かも @yasar710 が 3 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
CCExtractor/ccextractor#2449 ·
メンテナーはふだん 2 日以内に返信
-
[BUG] DVB subtitle decoder: heap-buffer-overflow write in dvbsub_parse_clut_segment via unbounded entry_id対応中かも @Aditya-Saroha が 5 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
CCExtractor/ccextractor#2440 ·
メンテナーはふだん 2 日以内に返信
-
Heap OOB read in parse_ad_cdp: cc_count not bounded by packet length対応中かも @Aditya-Saroha が 6 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
CCExtractor/ccextractor#2425 · コメント 3 件 ·
メンテナーはふだん 2 日以内に返信
-
[BUG] Heap buffer overflow in parse_PMT with C0/C1 section length対応中かも @kun-codes が 15 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
CCExtractor/ccextractor#2419 ·
メンテナーはふだん 2 日以内に返信
-
[BUG] Filename sequence expansion (`+`) panics on numeric values exceeding `i32::MAX`再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
CCExtractor/ccextractor#2402 ·
メンテナーはふだん 2 日以内に返信
CCExtractor/ccextractor の issue をすべて見る
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
メンテナーはふだん 10 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
sk3llo/ffmpeg_kit_flutter#176 ·
-
Synth suite fails unless run from the repo root: signal_flow's default machine path is cwd-relativeオープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
Nimblesite/osprey#370 ·
メンテナーはふだん 1 日以内に返信