# GPU accelerated video encode/decode with FFmpeg?



## Cromulent (Nov 23, 2022)

I'm curious if FreeBSD is suitable for GPU-accelerated video encoding/decoding and OpenCL/CUDA. What is the state of GPU drivers? I need to convert a lot of audio and video and will also be experimenting with machine learning, but I haven't read much about FreeBSD in this sphere.

Is AMD or Nvidia better for these tasks?


----------



## Alain De Vos (Nov 23, 2022)

For opencl there is ffmpeg.


----------



## Cromulent (Nov 23, 2022)

Alain De Vos said:


> For opencl there is ffmpeg.


Ah, sorry. I should have been clearer. I know FFmpeg supports GPU acceleration on Linux, but my query was about support from the GPU drivers on FreeBSD. OpenCL is fine.

On Linux, you need the proprietary drivers if you want to do things like this with Nvidia, and I'm curious if the situation is similar in FreeBSD.


----------



## SirDice (Nov 23, 2022)

No CUDA support unfortunately.


----------



## Cromulent (Nov 23, 2022)

SirDice said:


> No CUDA support unfortunately.


Thanks. So OpenCL and Vulkan then?


----------



## shkhln (Nov 23, 2022)

GPU encoding is mostly intended for streaming/transcoding. If you don't need realtime encoding, you should do it on the CPU for better quality at roughly 2x compression ratio.


----------



## Cromulent (Nov 23, 2022)

shkhln said:


> GPU encoding is mostly intended for streaming/transcoding. If you don't need realtime encoding, you should do it on the CPU for better quality at roughly 2x compression ratio.


I'll have to play around with things as I'll be encoding a lot of files, which is why I was looking for a couple of dedicated servers in my other thread. I guess the best I can do is test things out and see what specs I need and how much it costs.


----------



## dgmm (Nov 26, 2022)

shkhln said:


> GPU encoding is mostly intended for streaming/transcoding. If you don't need realtime encoding, you should do it on the CPU for better quality at roughly 2x compression ratio.


Agreed.  I'm no expect but do quite a lot of video re-encoding.  The general consensus on the 'net of those who are esperts seems to be that hardware GPU encoding can be quicker, but rarely as good as using s/w encoding with, eg FFMPeG, so it very much depends on how much one cares about quality over speed and the resolution one is working with.  On my own system, X265 encoding 1080p video will encode at approx. 1.5x real-time.  Scaling down and using lower, but more or less acceptable quality can encode at up to 4x real-time, all in s/w only with FFMPeG.

If you want the best possible quality at HD or better resolution, expect things to be a lot slower


----------



## Cromulent (Nov 27, 2022)

dgmm said:


> Agreed.  I'm no expect but do quite a lot of video re-encoding.  The general consensus on the 'net of those who are esperts seems to be that hardware GPU encoding can be quicker, but rarely as good as using s/w encoding with, eg FFMPeG, so it very much depends on how much one cares about quality over speed and the resolution one is working with.  On my own system, X265 encoding 1080p video will encode at approx. 1.5x real-time.  Scaling down and using lower, but more or less acceptable quality can encode at up to 4x real-time, all in s/w only with FFMPeG.
> 
> If you want the best possible quality at HD or better resolution, expect things to be a lot slower


Thank you. I'll play around with FFmpeg to ensure I get the right balance of quality and performance.


----------

