
Originally Posted by
TheFu
I need to find the way to get a GPU involved in h.265 encoding, if that is possible with my hardware AND the results are good enough. I suspect my GPUs are all too low-end for that, however.
I figured out how to use the GPU and to both h.264 and h.265 transcoding of videos. It runs between 3 and 20x faster, depending on the video codec used. The file output sizes and quality for the same size aren't anywhere as good as what Handbrake creates. There are fewer supported options with the hardware encoders, it seems. OTOH, it is nice NOT to see a CPU pegged for 30-60 minutes during transcoding.
I have a Ryzen 5600G. Using the iGPU for transcoding.
Recorded a Nature show off PBS last night. 62 minute recording. The recording was OTA at 1920x1080 with mpeg2/ac3 in a TS container. 4.0 GB in size. PBS only has commercials at the beginning and end of each show. I won't bother removing the leading/trailing commercials. It is just a watch-once show anyway.
Kicked off transcoding from mpeg2 to h.264 this morning - keeping the original resolution. 3MB/sec is the way to control the quality of the transcode. Should be fine.
It is running at 3.95x speed. So the full transcode will finish in about 15 minutes. Resolution is the main part of the "how long will this take" question.
Top shows the CPU 96+% idle.
Code:
load average: 0.58, 0.57, 0.58
%Cpu(s): 0.8 us, 0.6 sy, 1.2 ni, 97.4 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
If the CPU was being used, it would be 95% used and the load averages would be close to 12 (there are 12 cores).
Finished. Time says it was
Code:
real 15m36.074s
user 2m13.755s
sys 0m8.003s
The resulting h.264 file is 1.5G in size. I convert the AC3 stereo into 2-channel Vorbis audio as well. Comparing a few frames, the transcode is beautiful.
For fun, transcoded to h.265 as well, using the GPU. It is running at the same speed - just under 4x too, which surprises me. speed=3.92x
Code:
real 15m44.569s
user 2m17.008s
sys 0m10.169s
So h.265 transcoding time was about the same.
Code:
$ \du N*v
1554576 Nature-Attenborough_and_the_Jurassic_Sea_Monster-hevc-long.mkv
4146688 Nature-Attenborough_and_the_Jurassic_Sea_Monster-huge-mpg.mkv
1554404 Nature-Attenborough_and_the_Jurassic_Sea_Monster-long.mkv
Both use 3MB/sec as the maxrate, so the file sizes are the same. In theory, h.265 could use a lower bitrate for the same quality. When I tested using 2MB/sec, there were artifacts with h.265. Anyway, the result of the transcode is beautiful too.
Code:
Type h:m:s VCodec WxH VRate ACodec AChan Filename
-------- -------- ------ --------- ----- ------ ----- --------
lavfpref 62:00 hevc 1920:1080 29.97 VORB 2 Nature-Attenborough_and_the_Jurassic_Sea_Monster-hevc-long.mkv
lavfpref 62:00 mpeg2 1920:1080 29.97 ac3 2 Nature-Attenborough_and_the_Jurassic_Sea_Monster-huge-mpg.mkv
lavfpref 62:00 h264 1920:1080 29.97 VORB 2 Nature-Attenborough_and_the_Jurassic_Sea_Monster-long.mkv
I'm using Vorbis quality 6 (192Kbps) for audio. That, to me and many "audio experts", is indistinguishable from the source audio. I can't tell the difference between FLAC lossless audio and Vorbis at 192Kbps. I've tried. Can't.
BTW, the instructions I followed were in the Jellyfin HW Transcoding how-to. I was surprised how easy it was to setup. The HW transcoding also works in jellyfine. https://jellyfin.org/docs/general/ad...eleration/amd/ There are instructions there for Intel and Nvidia GPUs too, but I didn't look at them at all.
The scripts I use to batch encode are pretty trivial, just with lots of options that I don't want to type over and over and over. The transcode lines are very similar.
- h.264
Code:
nice /usr/lib/jellyfin-ffmpeg/ffmpeg \
-hwaccel vaapi \
-hwaccel_device /dev/dri/renderD128 \
-hwaccel_output_format vaapi \
-i "${file}" \
-map 0 \
-c:v h264_vaapi -b:v 3M -maxrate 3M \
-c:a libvorbis -q:a 6 \
"${new}-long.mkv"
- h.265
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 3M \
-c:a libvorbis -q:a 6 \
"${new}-hevc-long.mkv"
- h.264 using the CPU
Code:
nice /usr/lib/jellyfin-ffmpeg/ffmpeg -y -i "${file}" \
-map 0 -vcodec libx264 -crf 19.5 \
-preset medium -c:a libvorbis -q:a 6 \
"${file}.medium.long.mkv"
I wish the crf (quality) setting could be used with the HW encoding.
For archival, I still use handbrake and the CPU for encoding, usually with a 19.5 or 20 crf setting. I don't like artifacts. My ffmpeg SW encoding tests have never resulted in the same quality + small file size as what handbrake creates and certainly not as easily. I tested using all the "presents" for h.264 and was using "faster" as the watch-once setting. The time to encode with it was significantly faster than on medium and actually smaller than the "fast" preset for the same quality.
The "best" codec and transcoding method for your needs depends on the playback devices, quality demands, source material and how sensitive you are to file size. Since every DVD, every OTA recording, every Bluray are different sources with different encodings, there's no single answer for all inputs, all needs.
Anyway, probably more information than anyone wants. Hope it is useful to someone.