Reuse existing cuda context if possible when creating decoders

[ahmadsharif1]

Creating a cuda context is slow and takes about 400 MB of VRAM on GPU

This PR ensures we reuse the existing cuda context from pytorch when creating decoders

Thank you @fmassa for pointing out this issue and helping to resolve it.

Benchmark results show a decent speed-up, especially for short videos:

Before:

python benchmarks/decoders/gpu_benchmark.py --devices=cuda:0 --resize_devices=none --video ~/jupyter/frame_numbers_1920x1080.mp4

[------------------ Decode+Resize Time -----------------]
                     |  video=frame_numbers_1920x1080.mp4
1 threads: ----------------------------------------------
      D=cuda R=none  |                 2.0               

Times are in seconds (s).

After:

python benchmarks/decoders/gpu_benchmark.py --devices=cuda:0 --resize_devices=none --video ~/jupyter/frame_numbers_1920x1080.mp4

[------------------ Decode+Resize Time -----------------]
                     |  video=frame_numbers_1920x1080.mp4
1 threads: ----------------------------------------------
      D=cuda R=none  |                 1.3               

Times are in seconds (s).

This makes decoding single videos even without resize competitive with CPU:

[------------------ Decode+Resize Time -----------------]
                     |  video=frame_numbers_1920x1080.mp4
1 threads: ----------------------------------------------
      D=cuda R=none  |                 1.5               
      D=cpu R=none   |                 2.8               

Times are in seconds (s).

[NicolasHug]

Thanks @ahmadsharif1

[NicolasHug]

Can we clarify in the comment which major ffmpeg version 58 corresponds to?

[ahmadsharif1]

I was hesitant to put that in here because that could get stale. Different av* libraries get linked to different releases and there are minor releases too, but I added it here. It could potentially get stale

[NicolasHug]

Sorry for the noob Q - where are we ensuring this?

[ahmadsharif1]

The caller makes sure of that. The caller calls std::max on this deviceIndex. I'll rename this variable to be ffmpegCompatibleDeviceIndex so it's clear the max was already done.

[NicolasHug]

For my own understanding, are there existing docs (from ffmpeg or nvidia) that explain why deviceGuard() and cudaSetDevice() are needed?

[ahmadsharif1]

https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__DEVICE.html#group__CUDART__DEVICE_1g159587909ffa0791bbe4b40187a4c6bb tells you about cudaSetDevice

As to why it's needed, a context isn't available in a secondary thread so we make it available there before trying to reuse it