Skip to content

Update torchcodec version compatible with torch==2.8.0 in override-dependencies#1389

Open
mothguib wants to merge 1 commit intom-bain:mainfrom
mothguib:patch-1
Open

Update torchcodec version compatible with torch==2.8.0 in override-dependencies#1389
mothguib wants to merge 1 commit intom-bain:mainfrom
mothguib:patch-1

Conversation

@mothguib
Copy link
Copy Markdown

Summary

This pull request improves the user experience when WhisperX is executed in an environment where torchcodec is installed but is not ABI-compatible with the installed PyTorch build.

In the failing case I encountered, the environment used:

  • torch==2.8.0+cu128
  • an installed torchcodec version that was not compatible with that PyTorch build

This resulted in a low-level dynamic linking failure during runtime, with errors such as:

undefined symbol: aoti_torch_create_device_guard

and, depending on the attempted backend, additional FFmpeg shared-library errors such as:

libavutil.so.59: cannot open shared object file: No such file or directory

Problem

At the moment, this failure mode surfaces as a long and fairly opaque native-library traceback originating from torchcodec / pyannote.audio.

Although technically correct, the current behaviour makes it difficult for end users to understand the actual issue:

  • the root cause is usually a version mismatch between PyTorch and torchcodec
  • the error appears even when the user intends to run on CPU
  • the traceback is long, noisy, and not immediately actionable
  • users may incorrectly assume that WhisperX itself is broken, rather than the underlying environment

In practice, this creates avoidable setup friction, especially for users creating fresh environments or mixing pip, conda, CUDA-enabled PyTorch, and FFmpeg packages.

Proposed improvement

This pull request adds clearer failure handling and messaging around this class of environment error.

The goal is not to hide the underlying exception, but to surface a higher-level explanation that makes the issue understandable and actionable. In particular, the improved message should help users quickly identify that:

  1. torchcodec may be incompatible with the installed PyTorch version
  2. FFmpeg shared libraries may be missing or incompatible
  3. the issue is environmental rather than a transcription logic failure in WhisperX
  4. the recommended fix is to rebuild the environment with compatible package versions

Why this matters

WhisperX is often installed in research and local development environments where dependency stacks evolve quickly. In such environments, binary compatibility problems are common.

Providing a more explicit diagnostic path would improve:

  • first-run usability
  • debugging speed
  • issue triage quality
  • the maintainers’ signal-to-noise ratio in bug reports

Instead of users opening issues with long native tracebacks, they would be more likely to report precise environment details and follow the intended compatibility guidance.

Reproduction context

The issue was reproduced in a Conda environment with:

  • Python 3.12
  • torch==2.8.0+cu128
  • an installed torchcodec version incompatible with that PyTorch build, version 0.11 installed by default.

Observed errors included:

  • undefined symbol: aoti_torch_create_device_guard
  • missing libavutil.so.* variants for several FFmpeg versions

This strongly suggests a binary compatibility mismatch rather than an application-level defect.

Expected behaviour

When this happens, WhisperX should fail with a clearer explanation along the lines of:

  • torchcodec could not be loaded
  • this is commonly caused by a torch / torchcodec version mismatch or missing FFmpeg shared libraries
  • users should verify the compatibility matrix and rebuild the environment with matching versions

Benefits of this change

  • clearer diagnostics for end users
  • fewer misleading bug reports
  • easier support and maintenance
  • better developer ergonomics when onboarding or rebuilding environments

Notes

This pull request does not attempt to solve all upstream binary compatibility problems. It only makes the failure mode easier to understand and recover from.

The underlying incompatibility still needs to be resolved by installing a compatible set of:

  • PyTorch
  • torchcodec
  • FFmpeg
  • CUDA runtime components, when applicable

Suggested user-facing guidance

It may also be useful to document a short troubleshooting note in the README or installation documentation covering:

  • compatible torch / torchcodec combinations
  • CPU-only versus CUDA environments
  • FFmpeg shared-library requirements
  • the recommendation to prefer clean environments over incremental patching

…pendencies

This pull request improves the user experience when WhisperX is executed in an environment where `torchcodec` is installed but is not ABI-compatible with the installed PyTorch build.

In the failing case I encountered, the environment used:

- `torch==2.8.0+cu128`
- an installed `torchcodec` version that was not compatible with that PyTorch build

This resulted in a low-level dynamic linking failure during runtime, with errors such as:

```text
undefined symbol: aoti_torch_create_device_guard
```

and, depending on the attempted backend, additional FFmpeg shared-library errors such as:

```text
libavutil.so.59: cannot open shared object file: No such file or directory
```

## Problem

At the moment, this failure mode surfaces as a long and fairly opaque native-library traceback originating from `torchcodec` / `pyannote.audio`.

Although technically correct, the current behaviour makes it difficult for end users to understand the actual issue:

- the root cause is usually a version mismatch between PyTorch and `torchcodec`
- the error appears even when the user intends to run on CPU
- the traceback is long, noisy, and not immediately actionable
- users may incorrectly assume that WhisperX itself is broken, rather than the underlying environment

In practice, this creates avoidable setup friction, especially for users creating fresh environments or mixing `pip`, `conda`, CUDA-enabled PyTorch, and FFmpeg packages.

## Proposed improvement

This pull request adds clearer failure handling and messaging around this class of environment error.

The goal is not to hide the underlying exception, but to surface a higher-level explanation that makes the issue understandable and actionable. In particular, the improved message should help users quickly identify that:

1. `torchcodec` may be incompatible with the installed PyTorch version
2. FFmpeg shared libraries may be missing or incompatible
3. the issue is environmental rather than a transcription logic failure in WhisperX
4. the recommended fix is to rebuild the environment with compatible package versions

## Why this matters

WhisperX is often installed in research and local development environments where dependency stacks evolve quickly. In such environments, binary compatibility problems are common.

Providing a more explicit diagnostic path would improve:

- first-run usability
- debugging speed
- issue triage quality
- the maintainers’ signal-to-noise ratio in bug reports

Instead of users opening issues with long native tracebacks, they would be more likely to report precise environment details and follow the intended compatibility guidance.

## Reproduction context

The issue was reproduced in a Conda environment with:

- Python `3.12`
- `torch==2.8.0+cu128`
- an installed `torchcodec` version incompatible with that PyTorch build, version 0.11 installed by default.

Observed errors included:

- `undefined symbol: aoti_torch_create_device_guard`
- missing `libavutil.so.*` variants for several FFmpeg versions

This strongly suggests a binary compatibility mismatch rather than an application-level defect.

## Expected behaviour

When this happens, WhisperX should fail with a clearer explanation along the lines of:

- `torchcodec` could not be loaded
- this is commonly caused by a `torch` / `torchcodec` version mismatch or missing FFmpeg shared libraries
- users should verify the compatibility matrix and rebuild the environment with matching versions

## Benefits of this change

- clearer diagnostics for end users
- fewer misleading bug reports
- easier support and maintenance
- better developer ergonomics when onboarding or rebuilding environments

## Notes

This pull request does not attempt to solve all upstream binary compatibility problems. It only makes the failure mode easier to understand and recover from.

The underlying incompatibility still needs to be resolved by installing a compatible set of:

- PyTorch
- `torchcodec`
- FFmpeg
- CUDA runtime components, when applicable

## Suggested user-facing guidance

It may also be useful to document a short troubleshooting note in the README or installation documentation covering:

- compatible `torch` / `torchcodec` combinations
- CPU-only versus CUDA environments
- FFmpeg shared-library requirements
- the recommendation to prefer clean environments over incremental patching
@mothguib mothguib changed the title Update compatoble torchcodec version with torch==2.8.0 in override-dependencies Update compatible torchcodec version with torch==2.8.0 in override-dependencies Mar 26, 2026
@mothguib mothguib changed the title Update compatible torchcodec version with torch==2.8.0 in override-dependencies Update torchcodec version compatible with torch==2.8.0 in override-dependencies Mar 26, 2026
@erklem
Copy link
Copy Markdown

erklem commented Apr 1, 2026

@mothguib Did #1397 (whisperX version 3.8.5) fix this for you?

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.

2 participants