Repository navigation
[FIX] Honor 23.976 fps when importing SCC - #2452
harshalsp07 wants to merge 2 commits into
Conversation
|
sample 31 is byte-identical on master and this branch across 3 runs each. the approved first timestamp differs on both. could you rerun it? |
cfsmp3
left a comment
There was a problem hiding this comment.
This is Carlos' claude doing the first pass. Before Carlos takes a look, please address these issues.
The fix is correct, and its timing model (wall seconds plus frames × 1001/24) matches our SCC writer in ccx_encoders_scc.c, so import and export round-trip. One thing left:
tests/samples/scc_23_976.sccis added but nothing references it. Either drop it, or use it in a test (for example,include_str!it in the newtest_parse_scc_uses_23_976_framerate_from_ffiinstead of the inline string).
The sample file was unreferenced. include_str! it in the FFI framerate test and assert the parsed 608 byte pairs so both timing and content are covered.
CCExtractor CI platform finished running the test files on linux. 172/238 tests matched the approved output:
66 tests do not match the approved output. That is the pass/fail verdict. Whether this branch caused it is a separate question, answered below.
Compared with the tip of master — test 9984, commit 24d1e0a:
Compared with the commit this branch was cut from — test 9878, commit 185fe3f:
No test changes behaviour relative to the tip of master: every failure above fails there too, byte for byte. The approved output for those tests is out of date, which is a baseline to review rather than a regression in this branch. |
CCExtractor CI platform finished running the test files on windows. 130/238 tests matched the approved output:
108 tests do not match the approved output. That is the pass/fail verdict. Whether this branch caused it is a separate question, answered below.
Compared with the tip of master — test 9985, commit 24d1e0a:
Pass there, fail here:
Fail on both but produce different output — behaviour moved even though the verdict did not:
Compared with the commit this branch was cut from — test 9693, commit af4b28d:
Fail on both but produce different output — behaviour moved even though the verdict did not:
Fail there, pass here:
This branch changes the behaviour of 52 test(s) relative to the tip of master. Those are the ones worth looking at; anything else in the list fails the same way on both sides. |
In raising this pull request, I confirm the following (please check boxes):
Reason for this PR:
Sanity check:
--scc-framerate 23.976and its23.98alias are accepted by the CLI, but SCC import silently uses 29.97 fps. Both spellings become integer value 4;SccFrameRate::from_int()doesn't handle it and falls back to the default.Add the missing decoder rate and use
1001 / 24milliseconds per frame. The other rate mappings stay the same.Reproduce from the repository root with the included 90-byte sample:
The sample contains
HIbetween00:00:01:12and00:00:03:12. On masterd7eb132e, the SRT timing is00:00:01,401 --> 00:00:03,399. With this change it is00:00:01,501 --> 00:00:03,499. Repeating with23.98gives the same corrected timing.Tested on Linux:
cargo test --lockedinsrc/rust: 427 passed. The new SCC parsing test fails without the fix.cargo fmt --all -- --checkandcargo clippy -- -D warningspass.This fixes SCC input parsing. #2145 and #2406 concern CEA-708 SCC output timing. Windows/macOS and the external sample platform haven't been tested.
Follow-up local check on sample
b22260d065(platform regression 31): verified its SHA-256 and ran--autoprogram --out=srt --latin1three times on master's source and three times on this branch, with the same compiler and dependencies. All six runs exit 0 and produce identical 161,874-byte SRT files (SHA-256f5758a49bbe5fb46536c8a94b598f585ac0f92ac18bd451d862a8b3b57ecf561). Both builds start the first caption at00:00:04,838, while the platform's approved output expects00:00:02,635, so this does not establish an approved-output pass. The PR-specific difference reported by the hosted run was not reproduced locally; the platform test still needs a rerun.CI note: The initial Linux build stops before compilation because
libgpac-devhas no installation candidate on Ubuntu 26.04; #2428 addresses the runner change. The C format check also flagsccx_decoders_isdb.candmp4.c, which are unchanged from master.