There was a time when reading a video inside PyTorch could mean choosing among three backends, each with different constraints: PyAV available out of the box, a C++ FFmpeg backend and a CUDA/NVCUVID backend that had to be compiled from source and tied to specific versions. Audio was similarly split among StreamReader, StreamWriter and utilities with multiple dependencies. The PyTorch team has decided to close that chapter: decoding and encoding of images, video and audio now go through TorchCodec, on CPU and CUDA. TorchVision and TorchAudio do not disappear, but they narrow their scope to tensor transforms. Models, datasets and pipelines are no longer under active development: the team points to Hugging Face libraries as the natural alternative for that part.

The source is a post from the PyTorch team, not a commercial announcement, and it should be read as an architectural stance. Behind the rationalization there is a very concrete maintenance problem: media I/O drags along six major FFmpeg versions, NVIDIA's codec SDK for GPU decoding, and one library per image format, all in C/C++, none pure Python. This is not theoretical: it makes builds, CI and releases heavy, packaging errors more likely, and wheel distribution harder. Concentrating everything in TorchCodec isolates that complexity in a single place and lets TorchVision and TorchAudio have a leaner development cycle.

For teams doing local or self-hosted deployment of models that see or hear, the benefit is not so much the name of the library as the predictability. Before, you needed to figure out which API offered the right decoder and which backend was compiled in the distribution. Now the choice is one. This is not a detail: in air-gapped environments or with strict dependency control, every C/C++ library removed reduces attack surface and validation time. TorchCodec also aims at better performance, especially for CUDA video decoding. That has implications for training pipelines of multimodal or generative models, where data normalization can become the bottleneck before the GPU.

Why ABI stability shifts the incentives

The note about ABI-stable APIs is perhaps the most interesting signal. TorchCodec, TorchVision and TorchAudio are no longer tied to a single PyTorch version: a given version keeps working with later releases of the framework. For a team maintaining an on-premises fleet, this reduces the pressure to realign the whole stack at every PyTorch update. It is a change that loosens the lock-in between libraries and runtime, while shifting migration cost onto those still using the deprecated I/O APIs in TorchVision and TorchAudio. The migration guide exists to limit friction, but it does not erase the need to touch code, especially in TorchAudio, where several APIs were removed after a review with the community.

The reorganization also has a competitive effect. Transform functions remain under PyTorch, while model and dataset management effectively moves toward Hugging Face. That is not a surrender but a division of labor consistent with ecosystem evolution: the framework can no longer be the sole provider of every layer. The promised follow-up on individual library news and on extracting maximum performance from a full decoding and transform pipeline deserves attention. For now, the operational message is clear: anyone working with media in PyTorch should plan the move to TorchCodec, not just for convenience but because the old path will remain without active development.