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.
This eliminates the need for finding the dimensions of the input video prior to encoding.I've successfully set up quicksync and ffmpeg and then started to work on using both for transcoding. trunc(*iw/2)*2 and trunc(*iw/2)*2 ensure that the dimensions are divisible by 2 by dividing by 2, making the result an integer, then multiplying it back by 2.min(1,min(720/iw,400/ih) finds the scaling factor to fit within the bounding box (from here), constraining it to a maximum of 1 to ensure it only downscales, and.In this case, you can use expression evaluation in the scale function, like that used in Charlie's answer.Īssuming an output bounding box of 720x400: However, this does not work if your input video has a weird size and you are encoding to a format that requires the dimensions to be divisible by 2, resulting in an error. If you are trying to fit a bounding box, then using force_original_aspect_ratio as per xmedeko's answer is a good starting point.
0 kommentar(er)
