Decoding for playback isn't any issue. It is the encoding using the hardware that has poor quality. I'm running a test right now for you.
Recorded a TV show recently.
Code:
A. 6.9G The_Summit-Snakes_and_Ladd-huge-mpg.mkv <--- Commercials included 135:59 mpeg2/ac3 1080@29.97 fps
B. 3.2G The_Summit-Snakes_and_Ladd-h.mkv <--- Commercials removed 61:20 mpeg2/ac3 1080@29.97 fps
C. 3.1G The_Summit-Snakes_and_Ladd.mkv <--- Commercials removed 61:20 h.264/vorbis 1080@29.97 fps
D. 3.7G The_Summit-Snakes_and_Ladd-h.mkv-hevc-longhw.mkv <--- Commercials removed 61:20 hevc/vorbis 1080@29.97 fps
E. 3.2G The_Summit-Snakes_and_Ladd-h.mkv-longhw.mkv <--- Commercials removed 61:20 h.264/vorbis 1080@29.97 fps
A is the original recording put into an mkv container. It was actually a .ts file. For the show, an extra 45 min is recorded due to live sports sometimes shifting all shows later.
B is the original recording with all commercials removed and the extra 45 min from the following show cut. Typically, commercials add 50% to the file size and about 30% more time. A 1 hour show is 20 minutes of commercials, so removing commercials saves 20 minutes/hour.
C is the Handbrake transcode to h.264/vorbis/mkv container. Transcode time about 22 min. File size for 1080 videos is never great. The resulting video is beautiful. No artifacts at all. According to mediainfo, the overall bitrate is 7,055 kb/s
D is the HW encoding to hevc/vorbis/mkv using the Ryzen 5600G iGPU. Transcode time is 4.2x real time. About 15 min.
Code:
frame=109704 fps=124 q=-0.0 Lsize= 3809198kB time=01:01:20.81 bitrate=8477.7kbits/s dup=0 drop=490 speed=4.16x
video:3575544kB audio:228968kB subtitle:95kB other streams:0kB global headers:13kB muxing overhead: 0.120711%
real 14m45.889s
user 2m32.698s
sys 0m18.171s
The file is actually larger than the source to avoid video artifacts and yet it is still a little jumpy, unlike the smooth playback from the source. I spent about a week looking for the best settings to be used with the HW encoder. Mostly the video profile and Mbps control quality.
Code:
nice /usr/lib/jellyfin-ffmpeg/ffmpeg \
-hwaccel vaapi \
-hwaccel_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi \
-i "${file}" \
-map 0 \
-vf 'scale_vaapi=format=p010' \
-c:v hevc_vaapi -profile:v 2 -b:v 8M \
-c:a libvorbis -q:a 6 \
"${new}-hevc-longhw.mkv"
According to mediainfo, the overall bitrate is 8,478 kb/s
E is the HW encoding to h.264/vorbis/mkv using the Ryzen 5600G iGPU. It is currently running a 4.15x, so basically the same as the hevc HW encode. In general, since the h.264 and h.265 encodes take the same runtime, there's little reason to use the less efficient h.264 mode.
Code:
frame=109704 fps=123 q=-0.0 Lsize= 3343968kB time=01:01:20.81 bitrate=7442.3kbits/s dup=0 drop=490 speed=4.14x
video:3110317kB audio:228968kB subtitle:95kB other streams:0kB global headers:13kB muxing overhead: 0.137431%
real 14m49.422s
user 2m31.874s
sys 0m17.059s
The command used:
Code:
nice /usr/lib/jellyfin-ffmpeg/ffmpeg \
-hwaccel vaapi \
-hwaccel_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi \
-i "${file}" \
-map 0 \
-vf 'scale_vaapi=-2:1080' \
-c:v h264_vaapi -b:v 7M -maxrate 8M \
-c:a libvorbis -q:a 6 \
"${new}-longhw.mkv"
According to mediainfo, the overall bitrate is 7,442 kb/s
To be fair, this type of show with vast landscapes of sky, mountains, water, and subtle shades of green is really tough on encoders, so more bits are always required to maintain quality. Think Lord of the Rings mountains as what most of the show has. As I said before, the iGPU utilization doesn't impact regular CPU use that I can see. ffmpeg with HW encoding uses less than 20% of 1 core. Handbrake pegs all cores at 100%.
Remember, there are different goals for each type of encoding. The HW encodes place speed and qualify over file size. I don't intend to save those files forever, so I'm much less sensitive to file size and just want something that plays back on my player devices without any artifacts as the primary goal.
Handbrake encodes are for files I plan to keep forever. Typically, I'll encode using hevc, not h.264 with handbrake, since those file sizes for the same quality will be 50% smaller, but in my example above, I used h.264 because this is a TV show that won't be archived. It is a watch-once show.
