I did check the graphics utilization, just like the pdf suggested. I was wondering if there exists a way to utilize hardware acceleration even more and make transcoding with scaling using quicksync faster, as I don't really see the point of using it with ffmpeg otherwise. I assume this is because scaling calculations are done by the CPU instead of the GPU. This difference is further halved, if I run ffmpeg as several parallel processes. The difference is almost negligible, as libx264 consumes around 10% extra CPU but takes 5 seconds less. I've tested transcoding a single file into multiple outputs (each output has a different scale and pad filter) using both quicksync and libx264 - this is the main reason I am using ffmpeg along with qsv for. Not decoding with quicksync right now (besides, it doesn't really make a difference on this input file, since it's already in h264). Perhaps the difference would be much bigger if the input file was in a different codec. I should note that the initial input file is already in h264. However, when I try scaling and padding video filters, the difference between quicksync and libx264 becomes very small and transcoding speed using quicksync drops down to 1.84x (from 12.3x). When using libx264, the same command hangs around 9x speed.Ībove mentioned command: 'ffmpeg -y -i test_file -init_hw_device qsv:hw -c:v h264_qsv -preset veryfast -profile:v baseline -keyint_min 24 -g 48 -c:a aac -strict -2 -movflags faststart -b:v 3400k output.mp4'Īll is fine up to this point, as quicksync should be faster than libx264. When I run a simple transcode command, it processes with speed around 12.3x while using quicksync.

I've successfully set up quicksync and ffmpeg and then started to work on using both for transcoding.

H264_qsv