Last time I tried it, the situation was as follows:
For hardware transcoding to work the HDR tone mapping option must be switched off, which works fine for standard dynamic range material but produces low contrast, washed out output from HDR material.
If you switch on the HDR tone mapping option, then all transcoding is done by the CPU*, but both SDR and HDR material are treated correctly.
If, like me, you have very little HDR material you might consider the optimize function of Plex, which does a software transcode at your chosen resolution (there are presets for 1080, 720 and “original” resolutions) and bitrate and stores the result for future use, avoiding the need to transcode in real time, but obviously costing a little in storage space. I used the optimize function extensively when I had a weak CPU but spare storage.
*Note: there was an older version of the Plex app that allowed hardware decode (but not encode) when the HDR tone mapping option was on, and correctly handled HDR material. See my post of 14 February, above.
Aug 24, 2021 10:01:20.095 [0x7fb000cc3b38] Debug — [Transcode/JobRunner] Job running: FFMPEG_EXTERNAL_LIBS='/config/Library/Application\ Support/Plex\ Media\ Server/Codecs/be22e26-3998-linux-x86_64/' LIBVA_DRIVERS_PATH='/usr/lib/plexmediaserver/lib/dri' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/usr/lib/plexmediaserver/Plex Transcoder' '-codec:#0x01' 'h264' '-hwaccel:#0x01' 'vaapi' '-hwaccel_fallback_threshold:#0x01' '10' '-hwaccel_device:#0x01' 'vaapi' '-codec:#0x02' 'aac' '-analyzeduration' '20000000' '-probesize' '20000000' '-i' '/data/Test.mp4' '-filter_complex' '[0:#0x01]scale=w=1920:h=800[0];[0]format=pix_fmts=yuv420p|nv12[1]' '-map' '[1]' '-codec:0' 'libx264' '-crf:0' '16' '-maxrate:0' '2707k' '-bufsize:0' '5414k' '-r:0' '23.975999999999999' '-preset:0' 'veryfast' '-x264opts:0' 'subme=0:me_range=4:rc_lookahead=10:me=hex:8x8dct=0:partitions=none' '-force_key_frames:0' 'expr:gte(t,n_forced*3)' '-filter_complex' '[0:#0x02] aresample=async=1:ocl='\''stereo'\'':rematrix_maxval=0.000000dB:osr=44100[2]' '-map' '[2]' '-metadata:s:1' 'language=eng' '-codec:1' 'aac' '-b:1' '256k' '-f' 'dash' '-seg_duration' '3' '-dash_segment_type' 'mp4' '-init_seg_name' 'init-stream$RepresentationID$.m4s' '-media_seg_name' 'chunk-stream$RepresentationID$-$Number%05d$.m4s' '-window_size' '5' '-delete_removed' 'false' '-skip_to_segment' '1' '-time_delta' '0.0625' '-manifest_name' 'http://127.0.0.1:32400/video/:/transcode/session/06ru1rggxyrddo1smpv958pg/e7fed474-7849-4a5d-9bf8-9c7b8ebbb03f/manifest?X-Plex-Http-Pipeline=infinite' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-map_chapters' '-1' 'dash' '-start_at_zero' '-copyts' '-vsync' 'cfr' '-init_hw_device' 'vaapi=vaapi:' '-filter_hw_device' 'vaapi' '-y' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-progressurl' 'http://127.0.0.1:32400/video/:/transcode/session/06ru1rggxyrddo1smpv958pg/e7fed474-7849-4a5d-9bf8-9c7b8ebbb03f/progress'
Aug 24, 2021 10:01:20.908 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x3231564e -> nv12.
Aug 24, 2021 10:01:20.908 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x30313050 -> p010le.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x36313050 -> unknown.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x30323449 -> yuv420p.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x32315659 -> yuv420p.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x56595559 -> unknown.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x32595559 -> yuyv422.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x59565955 -> uyvy422.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x41524742 -> bgra.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x41424752 -> rgba.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x58524742 -> bgr0.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Debug — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Format 0x58424752 -> rgb0.
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Error — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Failed to create surface: 14 (the requested RT Format is not supported).
Aug 24, 2021 10:01:20.909 [0x7fb001138b38] Error — [Transcode/06ru1rggxyrddo1smpv958pg] [FFMPEG] - Unable to allocate a surface from internal buffer pool.
Aug 24, 2021 10:01:50.641 [0x7fb001138b38] Debug — [Transcode/1vp3nyz08ic5tmnq0o2w3eyt/JobRunner] Job running: FFMPEG_EXTERNAL_LIBS='/config/Library/Application\ Support/Plex\ Media\ Server/Codecs/be22e26-3998-linux-x86_64/' LIBVA_DRIVERS_PATH='/usr/lib/plexmediaserver/lib/dri' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/usr/lib/plexmediaserver/Plex Transcoder' '-codec:#0x01' 'h264' '-hwaccel:#0x01' 'vaapi' '-hwaccel_fallback_threshold:#0x01' '10' '-hwaccel_device:#0x01' 'vaapi' '-codec:#0x02' 'aac' '-ss' '72' '-analyzeduration' '20000000' '-probesize' '20000000' '-i' '/data/Test.mp4' '-filter_complex' '[0:#0x01]scale=w=1920:h=800[0];[0]format=pix_fmts=yuv420p|nv12[1]' '-map' '[1]' '-codec:0' 'libx264' '-crf:0' '16' '-maxrate:0' '2707k' '-bufsize:0' '5414k' '-r:0' '23.975999999999999' '-preset:0' 'veryfast' '-x264opts:0' 'subme=0:me_range=4:rc_lookahead=10:me=hex:8x8dct=0:partitions=none' '-force_key_frames:0' 'expr:gte(t,n_forced*3)' '-filter_complex' '[0:#0x02] aresample=async=1:ocl='\''stereo'\'':rematrix_maxval=0.000000dB:osr=44100[2]' '-map' '[2]' '-metadata:s:1' 'language=eng' '-codec:1' 'aac' '-b:1' '256k' '-f' 'dash' '-seg_duration' '3' '-dash_segment_type' 'mp4' '-init_seg_name' 'init-stream$RepresentationID$.m4s' '-media_seg_name' 'chunk-stream$RepresentationID$-$Number%05d$.m4s' '-window_size' '5' '-delete_removed' 'false' '-skip_to_segment' '25' '-time_delta' '0.0625' '-manifest_name' 'http://127.0.0.1:32400/video/:/transcode/session/1vp3nyz08ic5tmnq0o2w3eyt/aca9880f-2861-4a86-a0ad-976653844a12/manifest?X-Plex-Http-Pipeline=infinite' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-map_chapters' '-1' 'dash' '-start_at_zero' '-copyts' '-init_hw_device' 'vaapi=vaapi:' '-filter_hw_device' 'vaapi' '-y' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-progressurl' 'http://127.0.0.1:32400/video/:/transcode/session/1vp3nyz08ic5tmnq0o2w3eyt/aca9880f-2861-4a86-a0ad-976653844a12/progress'
Aug 24, 2021 10:01:50.732 [0x7fb000d2bb38] Error — [Transcoder] [AVHWFramesContext @ 0x7f227209eec0] Failed to create surface: 14 (the requested RT Format is not supported).
Aug 24, 2021 10:01:50.733 [0x7fb000cc3b38] Error — [Transcoder] [AVHWFramesContext @ 0x7f227209eec0] Unable to allocate a surface from internal buffer pool.
Aug 24, 2021 10:01:50.733 [0x7fb00231fb38] Error — [Transcoder] [h264 @ 0x7f2271aab3c0] Failed setup for format vaapi_vld: hwaccel initialisation returned error.
Yeah, same with the current version. No issues with Plex’s new usage of musl but the encoder/decoder pipeline still fails to be setup for vaapi in recent versions. @ChuckPa is this something the Transcoder team could look into? Has VAAPI support been dropped?
This has been done in recent built attempts.
So it’s not the transcode binary dying or any unresolved libs, the way the
transcoder sets up it’s pipeline has fundamentally changed. Whereas in older
builds it was able to detect and utilize VAAPI to utilize HW decoding on Ryzen CPUs and Radeon GPUs it’s now failing to setup the decoding pipeline in the first place (at least that’s what I gather from the logs I posted).
I did another attempt basing everything off spritsails docker container for Plex. The upshot there is that it’s all based on Alpine and thus MUSL, eliminating any weird libc problems that one might encounter when copying libs from an Ubuntu/Debian based container.
HW accelerated decoding seems to work, however HW transcoding seems to be still problematic (Something that definitely did work before the new toolchain was introduced).
Attaching relevant log snippet:
Aug 29, 2021 18:40:46.985 [0x7f3efda20b38] Debug — [Transcode] Codecs: hardware transcoding: testing API vaapi
Aug 29, 2021 18:40:46.985 [0x7f3efda20b38] Verbose — [Transcode] [FFMPEG] - Trying to use DRM render node for device 0.
Aug 29, 2021 18:40:46.985 [0x7f3efda20b38] Verbose — [Transcode] [FFMPEG] - libva: VA-API version 1.10.0
Aug 29, 2021 18:40:46.985 [0x7f3efda20b38] Verbose — [Transcode] [FFMPEG] - libva: Trying to open /usr/lib/plexmediaserver/lib/dri/radeonsi_drv_video.so
Aug 29, 2021 18:40:46.985 [0x7f3efda20b38] Verbose — [Transcode] [FFMPEG] - libva: Found init function __vaDriverInit_1_10
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Verbose — [Transcode] [FFMPEG] - libva: va_openDriver() returns 0
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Verbose — [Transcode] [FFMPEG] - Initialised VAAPI connection: version 1.10
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x3231564e -> nv12.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x30313050 -> p010le.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x36313050 -> unknown.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x30323449 -> yuv420p.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x32315659 -> yuv420p.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x56595559 -> unknown.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x32595559 -> yuyv422.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x59565955 -> uyvy422.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x41524742 -> bgra.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x41424752 -> rgba.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x58524742 -> bgr0.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Format 0x58424752 -> rgb0.
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Verbose — [Transcode] [FFMPEG] - VAAPI driver: Mesa Gallium driver 20.3.3 for AMD RENOIR (DRM 3.40.0, 5.11.8-051108-generic, LLVM 10.0.1).
Aug 29, 2021 18:40:47.007 [0x7f3efda20b38] Verbose — [Transcode] [FFMPEG] - Driver not found in known nonstandard list, using standard behaviour.
Aug 29, 2021 18:40:47.031 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Created surface 0x1.
Aug 29, 2021 18:40:47.031 [0x7f3efda20b38] Debug — [Transcode] [FFMPEG] - Direct mapping disabled: deriving image does not work: 1 (operation failed).
Aug 29, 2021 18:40:47.036 [0x7f3efda20b38] Debug — [Transcode] TPU: hardware transcoding: final decoder: vaapi, final encoder:
Maybe we can get someone from the Transcoder team to shed some more light on this?
These updates + last working versione allow HW transcoding (both decoding and encoding) via AMD APU integrated graphic. (HDR tone mapping not flagged)
By design Plex HW transcoding doesn’t work with AMD integrated graphics.
Whats that supposed to mean. It used to work but now it doesn’t. Plex HW transcoding supports VAAPI as such it is designed to work with anything that implements VAAPI. Including AMD i- and dGPUs.
There’s been a re-design/rejigg of the Transcoder pipeline and something regressed. That’s the problem.
Well yes, but not completely accurate. Plex claims to support HW decoding and encoding via VAAPI. And AMD implements the VAAPI interface, so by design it should have always worked (just that because Plex didn’t copy/include the AMD gallium drivers (at least in the docker images I tried))
Thank you for the patch, man. Confirmed working with my Ryzen 4750U apu Vega 8 igpu (pms version 1.22.4392 running on ubuntu with HDR tone mapping turned off). but I just don’t get it why it stops working after updates. Is there any plans if the Plex team is going to fix it or officially supports hardware transcoding on linux platform?
There’s really not anything I can do without some help from Plex’s Transcoder team. I have a container that is all ready to go from a library/VAAPI point of view. Built with the most recent Mesa drivers for AMD GPUs. What needs to be resolved is the setup of the pipeline. Right now all I can get out of it is HW accelerated decoding.
Since switching to MUSL, there’s probably a small config file you’re not aware of.
We (mostly I) include for the various platforms on a per-platform basis.
What you need to take into consideration (ADD) for all packages since the MUSL change (1.23.0) is /usr/lib/plexmediaserver/etc/ld-musl-x86_64.path
In this file, you put the pathnames to all your AMD gallium drivers, etc
As a starting point, here’s the code I use for QNAP.
This scripting dynamically updates the file based on the detection of a valid (available) Nvidia card because QNAP allows the card(s) to be dedicated to VMs or Containers
# Construct ld-musl-x86_64.path
{
echo /lib
echo /usr/lib
echo /usr/local/lib
echo /usr/local/cuda/lib64
} > ${QPKG_DIR}/etc/ld-musl-x86_64.path
# If GPU is supported (Has Drivers & Is Available)
if [ $SUPPORTED_GPU -gt 0 ]; then
# determine and write paths (QTS & QuTS)
GPU_DRV_DIR="$(echo /share/*/.qpkg/NVIDIA_GPU_DRV/usr/lib)"
[ "$GPU_DRV_DIR" != "/share/*/.qpkg/NVIDIA_GPU_DRV/usr/lib" ] && echo $GPU_DRV_DIR >> ${QPKG_DIR}/etc/ld-musl-x86_64.path
# Older versions
if [ -d "/opt/NVIDIA_GPU_DRV" ]; then
{
echo /opt/NVIDIA_GPU_DRV/usr/syslib
echo /opt/NVIDIA_GPU_DRV/usr/lib
echo /opt/NVIDIA_GPU_DRV/usr/applib
} >> ${QPKG_DIR}/etc/ld-musl-x86_64.path
fi
fi
We’re already beyond this. The libraries are found, I posted the logs showing Plex initializing VAAPI already. For whatever reason it fails to setup the encoding pipeline (decoding is used with HW accel), something that did work before the rejig of the transcoder.
Haha, no worries. Thanks for having a second look.
No subtitles in my test file. But I’ll go back and test again to doubly ensure I am not testing the wrong thing
