Add ROCJPEG decoder

[NicolasHug]

Ported from TV.

Would need #1553 first but trying to make progress on this now

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/meta-pytorch/torchcodec/1554

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 Unclassified Failure

As of commit e8d2e04 with merge base d249ad5 ():

UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:

• Linux ROCm x86 / install-and-test (3.10, 7.1) / linux-job (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  test/test_decoders.py::TestImageDecoder::test_cuda_jpeg_multithreaded

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[jithunnair-amd]

@NicolasHug For ROCm versions >= 7.14, the RPATH solution would work (for Linux at least). For ROCm 7.2 and earlier, would you want us to implement the same bundling logic here that we had in torchvision?
Cc @akashveramd

[jithunnair-amd]

@NicolasHug For ROCm versions >= 7.14, the RPATH solution would work (for Linux at least). For ROCm 7.2 and earlier, would you want us to implement the same bundling logic here that we had in torchvision? Cc @akashveramd

Pardon, I see that the intent in this PR is not to bundle, and instead install the rocjpeg dependency explicitly at build and test time: packaging/install_rocjpeg.sh

@akashveramd In that case, assuming that this is a problem of locating librocjpeg, it should be a matter of ensuring that the ROCm 7.2 and earlier builds can locate the librocjpeg.so being installed via the above script.

@NicolasHug This might come down to using LD_LIBRARY_PATH or RPATH (but the latter would need to assume an /opt/rocm installation, which is not always strictly true). The LD_LIBRARY_PATH should fix it for the CI env, but users of torchcodec wheels may still see the issue. The latter should fix it for most torchcodec users (except those who have ROCm installed in a non-/opt/rocm path; they would need to set LD_LIBRARY_PATH anyway).

Please let us know what you'd prefer.

[NicolasHug]

Ideally the ROCm TorchCodec wheel would ship the relevant rocjpeg libs, just like the CUDA wheels are shipping libnvjpeg.

But claude is saying this:

rocJPEG is not shipped by the torch-ROCm
wheel, and bundling it would drag in torch's ROCm libs under mismatched
(hashed) sonames. So we treat it as a runtime dependency provided by the
ROCm install, like FFmpeg. decode_jpeg(device='cuda') therefore needs
ROCm (with rocJPEG) present at runtime.

I haven't verified this claim - if you can find a way to properly bundle the rocjpeg libs, I'm happy to bundle them.

[jithunnair-amd]

Ideally the ROCm TorchCodec wheel would ship the relevant rocjpeg libs, just like the CUDA wheels are shipping libnvjpeg.

But claude is saying this:

rocJPEG is not shipped by the torch-ROCm
wheel, and bundling it would drag in torch's ROCm libs under mismatched
(hashed) sonames. So we treat it as a runtime dependency provided by the
ROCm install, like FFmpeg. decode_jpeg(device='cuda') therefore needs
ROCm (with rocJPEG) present at runtime.

I haven't verified this claim - if you can find a way to properly bundle the rocjpeg libs, I'm happy to bundle them.

@akashveramd please take note

[akashveramd]

@NicolasHug: It seems the wheels is build and uploaded for ROCm 7.1 & 7.2. But the test runs only on 7.1. Do we want to run the test on both 7.1 & 7.2 or build only on one ROCm version?
FYI, I will be replacing ROCm 7.1/7.2 with 7.2/7.14 version.

[NicolasHug]

I am happy to add more coverage if there is value there, but my priority is to make the 7.1 (or any other version) work correctly at the moment