2025-01-28, 02:13 PM
(This post was last modified: 2025-01-28, 02:13 PM by TheDreadPirate.)
You did not fully initialize the GPU. Nor did you construct the ffmpeg command properly. Parameter order matters and hardware initialization belong on the "input" side of the command. As in before "-i FILENAME". All parameters to the right of the input file are the "output" parameters.
Move -init_hw_device to the left of your file input. Then add these parameters on the input side to fully initialize your GPU.
hwaccel = hardware DECODING. Without this it would CPU decode. Some codecs that are not supported by an Arc GPU would require you omit this parameter. Like VC1.
hwaccel_output_format = hardware encoding.
filter_hw_device qs = filters for QSV devices. Helpful if you also have AMD GPUs in the system. Wouldn't need to specify which render device if you only have one of each type.
Since you are using "look_ahead_depth" you should also add this to the input side.
So the full command would be this.
I also moved fflags to the input side. And "low_power" is not needed for AV1 since only H264 and HEVC have low power modes. I also added "max_muxing_queue_size 2048". This can help prevent some edge cases from causing ffmpeg to fail. "max_interleave_delta 0" also helps ensure that the output file is interleaved "evenly". Some files that are poorly muxed will have huge gaps in between tracks that can cause issues with some video players. The side effect is that some very poorly muxed files will cause ffmpeg to keep reading the file, storing it in memory, until it encounters all the tracks. If ffmpeg fails due to running out of memory you can try omitting max_interleave_delta.
If your CPU's GPU is still enabled you may need to use renderD129 instead of 128.
Move -init_hw_device to the left of your file input. Then add these parameters on the input side to fully initialize your GPU.
Code:
-filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv
hwaccel = hardware DECODING. Without this it would CPU decode. Some codecs that are not supported by an Arc GPU would require you omit this parameter. Like VC1.
hwaccel_output_format = hardware encoding.
filter_hw_device qs = filters for QSV devices. Helpful if you also have AMD GPUs in the system. Wouldn't need to specify which render device if you only have one of each type.
Since you are using "look_ahead_depth" you should also add this to the input side.
Code:
-extra_hw_frames 40
So the full command would be this.
Code:
/usr/lib/jellyfin-ffmpeg/ffmpeg -fflags +nobuffer+discardcorrupt+genpts+flush_packets -init_hw_device vaapi=va:/dev/dri/renderD128 -filter_hw_device qs -hwaccel qsv -hwaccel_output_format qsv -extra_hw_frames 40 -i ballon.1080p.mkv -c:v av1_qsv -preset veryslow -extbrc 1 -low_delay_brc 1 -look_ahead_depth 40 -b:v 1M -bufsize 2M -rc_init_occupancy 512K -adaptive_i 1 -adaptive_b 1 -b_strategy 1 -bf 7 -map 0:a? -c:a aac -b:a 64k -map 0:s? -c:s copy -max_muxing_queue_size 2048 -max_interleave_delta 0 -avoid_negative_ts disabled ballon.av1.mkv
I also moved fflags to the input side. And "low_power" is not needed for AV1 since only H264 and HEVC have low power modes. I also added "max_muxing_queue_size 2048". This can help prevent some edge cases from causing ffmpeg to fail. "max_interleave_delta 0" also helps ensure that the output file is interleaved "evenly". Some files that are poorly muxed will have huge gaps in between tracks that can cause issues with some video players. The side effect is that some very poorly muxed files will cause ffmpeg to keep reading the file, storing it in memory, until it encounters all the tracks. If ffmpeg fails due to running out of memory you can try omitting max_interleave_delta.
If your CPU's GPU is still enabled you may need to use renderD129 instead of 128.