Skip to content

Release 2026-09-03 (i4 3f2febdb) - #231

Merged
lfengad merged 2 commits into
mainfrom
release/2026-09-03-3f2febdb
Sep 3, 2026
Merged

Release 2026-09-03 (i4 3f2febdb)#231
lfengad merged 2 commits into
mainfrom
release/2026-09-03-3f2febdb

Conversation

@yy-code-nv

Copy link
Copy Markdown
Collaborator

Automated release from i4.

_source_commit: 3f2febdb626b29757fe189849367fe8be500229b-dirty
_dest_commit (base): 4bc4392b615a2d6719313a368f81540117e5e405

_source_commit: 3f2febdb626b29757fe189849367fe8be500229b-dirty
_dest_commit:   4bc4392
…efault (#232)

## What

Fixes the `generator-inference-smoke` failure on #231.

`_build_decoder` forwards `output_dtype=torch.uint8` into
`VideoDecoder(...)` on **every** call:

```python
kwargs: dict[str, Any] = {"num_ffmpeg_threads": num_ffmpeg_threads, "output_dtype": output_dtype}
```

`output_dtype` does not exist on the pinned TorchCodec. `pyproject.toml`
resolves `cu128` and `cu130` to `torchcodec==0.10.0`, whose
`VideoDecoder.__init__` is:

```python
def __init__(self, source, *, stream_index=None, dimension_order="NCHW",
             num_ffmpeg_threads=1, device=None, seek_mode="exact",
             transforms=None, custom_frame_mappings=None):
```

Only the `cu130-torch213` group pins a release new enough (`0.14.0`).
Every CI job runs `--group=cu128-train`, so every decoder construction —
including plain metadata probes via `probe_video()` — raised:

```
TypeError: VideoDecoder.__init__() got an unexpected keyword argument 'output_dtype'
```

uint8 is already 0.10's native output, so the default carried no
information and only broke the call.

## Why the failure was so expensive to read

In `test_nano_inference_omni` it was **rank 1** that raised. The other
three ranks carried on into an `ALLREDUCE` and sat there until the 1800s
NCCL watchdog fired, at which point `ProcessGroupNCCL` took them down
with `SIGABRT` (exitcode `-6`, `traceback: NoneType: None`). 30 of the
job's 36 minutes were the timeout, and the real one-line `TypeError` was
~950 lines above the reported failure.

The same bug in `test_nano_inference_multi_control_transfer` hit **rank
0** and failed cleanly in ~14 seconds — same root cause, completely
different-looking failure, decided purely by which rank got there first.

## The fix

- Send `output_dtype` only when it differs from the `uint8` default,
restoring the default path to its pre-regression behaviour.
- Translate a rejected `output_dtype` / `transforms` keyword into a
message naming the knob and the installed version, so a genuine request
on an old build fails legibly instead of as a bare `TypeError` deep
inside a rank.

No caller anywhere in the repo passes `output_dtype` or `resize_size`,
so nothing loses functionality. `transforms` **does** exist on 0.10.0
and is unaffected; it is covered by the same guard for older builds.

`interleaved_video_parsing.py` already carries this exact defensive
pattern (`_SUPPORTS_VIDEO_DECODER_OUTPUT_DTYPE`, the cached `TypeError`
probe). It just was not applied to `torchcodec_video.py`.

## Tests

`torchcodec_video.py` had **no test file at all** — which is why a
pure-Python signature mismatch had to be caught by a 4-GPU inference
smoke test instead of a unit test.

Adds `torchcodec_video_test.py` (6 tests). The decoders in it mirror the
real 0.10.0 and newer signatures rather than whatever CI resolved, so
the behaviour is pinned on both. Verified red→green: the 3 compatibility
tests fail against the current code with the exact production error
(`torchcodec_video.py:59`) and pass after the fix. `ruff check` and
`ruff format --check` are clean on both files.

## Base

Targets `release/2026-09-03-3f2febdb` so #231 can go green.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@lfengad
lfengad enabled auto-merge (squash) September 3, 2026 14:37
@lfengad
lfengad disabled auto-merge September 3, 2026 15:15
@lfengad
lfengad merged commit 6ea6966 into main Sep 3, 2026
9 checks passed
@lfengad
lfengad deleted the release/2026-09-03-3f2febdb branch September 3, 2026 15:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants