I haven’t tried a different PMS version on this VM yet since I thought it was more the GPU passthrough that was causing plex to get confused… If you’re saying that its a bug on the plex.tv side of things, then I’ll wait until its fixed…
Strange though that it does indicate it is hardware transcoding (deconding / encoding) in the original plex.tv image, especially if it can’t get the codec?
Thanks for your help with this!
with some rest under the belt.
I will look for the precursor and secondary errors. The codec manager should have reported it cannot download
Do you have the fan-based “transcoder script” in use?
Hi @ChuckPa,
(1) Stopped Plex and recreated empty Codecs dir and did dir listing:
/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Codecs$ ls -laR
.:
total 8
drwxr-xr-x 2 plex plex 4096 Mar 31 08:38 .
drwxr-xr-x 17 plex plex 4096 Mar 31 08:38 ..
(2) Cleared Plex Logs
(3) Started plex
(4) Played a H264/AAC movie (using Direct Play) - From 08:53:00
(5) Stopped playback and told client to play same media but at reduced 480p quality (forcing transcoding) - From 08:55:00
(6) Downloaded Logs…
Where should I send the logs to? Would rather not post the full logs on the forums?
What’s the “fan based transcoder script”?
The “fan based” script modifies parameters passed to the transcoder. Use of it, while it may work for most, will confuse me if in use without knowing.
I’ve uploaded the Application.log as requested.
Thank you for the logs.
The first log shows me Plex is finding and using the ASIC in the CPU . It does not complain about not finding the codec.
Mar 31, 2019 08:55:07.381 [0x7f383effd700] INFO - CodecManager: obtaining decoder 'h264'
Mar 31, 2019 08:55:07.381 [0x7f383effd700] DEBUG - HTTP requesting GET https://plex.tv/api/codecs/h264_decoder?build=linux-x86_64-standard&deviceId=99879b5b-fc36-48c9-9347-045efb89e8d2&oldestPreviousVersion=1%2E15%2E1%2E791-8bec0f76c&version=a22632d-2132
Mar 31, 2019 08:55:07.643 [0x7f387c88d700] DEBUG - Auth: authenticated user 1 as ninja888plex
Mar 31, 2019 08:55:07.643 [0x7f383f7fe700] DEBUG - Request: [42.190.234.61:50247 (WAN)] GET /statistics/bandwidth?timespan=6 (14 live) TLS GZIP Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:07.646 [0x7f3877fff700] DEBUG - Completed: [42.190.234.61:50247] 200 GET /statistics/bandwidth?timespan=6 (14 live) TLS GZIP 3ms 1640 bytes (pipelined: 30)
Mar 31, 2019 08:55:08.333 [0x7f383effd700] DEBUG - HTTP 200 response from GET https://plex.tv/api/codecs/h264_decoder?build=linux-x86_64-standard&deviceId=99879b5b-fc36-48c9-9347-045efb89e8d2&oldestPreviousVersion=1%2E15%2E1%2E791-8bec0f76c&version=a22632d-2132
Mar 31, 2019 08:55:08.334 [0x7f383effd700] DEBUG - HTTP requesting GET https://downloads.plex.tv/codecs/a22632d-2132/linux-x86_64-standard/libh264_decoder.so
Mar 31, 2019 08:55:08.552 [0x7f383effd700] DEBUG - HTTP 200 response from GET https://downloads.plex.tv/codecs/a22632d-2132/linux-x86_64-standard/libh264_decoder.so
Mar 31, 2019 08:55:08.674 [0x7f383effd700] DEBUG - TPU: hardware transcoding: using hardware decode accelerator vaapi
Mar 31, 2019 08:55:08.674 [0x7f383effd700] INFO - CodecManager: obtaining decoder 'aac'
Mar 31, 2019 08:55:08.674 [0x7f383effd700] DEBUG - HTTP requesting GET https://plex.tv/api/codecs/aac_decoder?build=linux-x86_64-standard&deviceId=99879b5b-fc36-48c9-9347-045efb89e8d2&oldestPreviousVersion=1%2E15%2E1%2E791-8bec0f76c&version=a22632d-2132
It specifically calls out at the same instance in time.
Mar 31, 2019 08:55:08.674 [0x7f383effd700] DEBUG - TPU: hardware transcoding: using hardware decode accelerator vaapi**
Of particular importance, -codec:0 h264_vaapi (Hardware H264)
and the flow of data
Mar 31, 2019 08:55:09.728 [0x7f383effd700] DEBUG - TPU: hardware transcoding: zero-copy support present
Mar 31, 2019 08:55:09.728 [0x7f383effd700] DEBUG - TPU: hardware transcoding: using zero-copy transcoding
Mar 31, 2019 08:55:09.751 [0x7f383effd700] DEBUG - TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi
Mar 31, 2019 08:55:09.752 [0x7f383effd700] DEBUG - Job running: EAE_ROOT='/tmp/pms-ce8e0556-766c-4389-9393-86b218d0c1d1/EasyAudioEncoder' FFMPEG_EXTERNAL_LIBS='/var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server/Codecs/a22632d-2132-linux-x86_64/' XDG_CACHE_HOME='/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Cache' XDG_DATA_HOME='/usr/lib/plexmediaserver/Resources' X_PLEX_TOKEN='xxxxxxxxxxxxxxxxxxxx' '/usr/lib/plexmediaserver/Plex Transcoder' '-codec:#0x01' 'h264' '-hwaccel:#0x01' 'vaapi' '-hwaccel_fallback_threshold:#0x01' '10' '-hwaccel_output_format:#0x01' 'vaapi' '-codec:#0x02' 'aac' '-analyzeduration' '20000000' '-probesize' '20000000' '-i' '/mnt/DS1515/video/Movies/Free.Solo.2018.WEB-DL.x264-FGT/Free.Solo.2018.WEB-DL.x264-FGT.mp4' '-filter_complex' '[0:#0x01]hwupload[0];[0]scale_vaapi=w=712:h=384:format=nv12[1];[1]hwupload[2]' '-filter_complex' '[0:#0x02] aresample=async=1:ocl='\''stereo'\'':osr=48000[3]' '-map' '[2]' '-metadata:s:0' 'language=eng' '-codec:0' 'h264_vaapi' '-b:0' '959k' '-maxrate:0' '1279k' '-bufsize:0' '2558k' '-r:0' '23.975999999999999' '-force_key_frames:0' 'expr:gte(t,0+n_forced*8)' '-map' '[3]' '-metadata:s:1' 'language=eng' '-codec:1' 'libopus' '-b:1' '133k' '-segment_format' 'matroska' '-f' 'ssegment' '-individual_header_trailer' '0' '-flags' '+global_header' '-segment_format_options' 'output_ts_offset=10' '-segment_header_filename' 'header' '-segment_time' '8' '-segment_start_number' '0' '-segment_copyts' '1' '-segment_time_delta' '0.0625' '-segment_list' 'http://127.0.0.1:32400/video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/seglist' '-segment_list_type' 'csv' '-segment_list_size' '2147483647' '-segment_list_separate_stream_times' '1' '-max_delay' '5000000' '-avoid_negative_ts' 'disabled' '-map_metadata' '-1' '-map_chapters' '-1' 'media-%05d.ts' '-start_at_zero' '-copyts' '-vsync' 'cfr' '-y' '-vaapi_device' '/dev/dri/renderD128' '-nostats' '-loglevel' 'quiet' '-loglevel_plex' 'error' '-progressurl' 'http://127.0.0.1:32400/video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress'
Mar 31, 2019 08:55:09.868 [0x7f383effd700] DEBUG - Jobs: Starting child process with pid 12594
Mar 31, 2019 08:55:10.014 [0x7f383e7fc700] DEBUG - Request: [127.0.0.1:57482 (Loopback)] PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress?status=startup (13 live) Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:10.014 [0x7f3877fff700] DEBUG - Completed: [127.0.0.1:57482] 204 PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress?status=startup (13 live) 0ms 203 bytes (pipelined: 1) (range: bytes=0-)
Mar 31, 2019 08:55:10.014 [0x7f381d7fa700] DEBUG - Request: [127.0.0.1:57482 (Loopback)] PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress?status=opening (13 live) Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:10.014 [0x7f3877fff700] DEBUG - Completed: [127.0.0.1:57482] 204 PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress?status=opening (13 live) 0ms 203 bytes (pipelined: 2) (range: bytes=0-)
Mar 31, 2019 08:55:10.065 [0x7f383f7fe700] DEBUG - Request: [127.0.0.1:57482 (Loopback)] PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress?status=opened (13 live) Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:10.065 [0x7f3877fff700] DEBUG - Completed: [127.0.0.1:57482] 204 PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress?status=opened (13 live) 0ms 203 bytes (pipelined: 3) (range: bytes=0-)
Mar 31, 2019 08:55:10.065 [0x7f383e7fc700] DEBUG - Request: [127.0.0.1:57482 (Loopback)] PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress/stream?index=0&id=1&codec=h264&type=video (13 live) Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:10.065 [0x7f3877fff700] DEBUG - Completed: [127.0.0.1:57482] 206 PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress/stream?index=0&id=1&codec=h264&type=video (13 live) 0ms 256 bytes (pipelined: 4) (range: bytes=0-)
Mar 31, 2019 08:55:10.067 [0x7f381cff9700] DEBUG - Request: [127.0.0.1:57482 (Loopback)] PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress/stream?index=1&id=2&codec=aac&type=audio&profile=LC (13 live) Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:10.067 [0x7f387c88d700] DEBUG - Completed: [127.0.0.1:57482] 206 PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress/stream?index=1&id=2&codec=aac&type=audio&profile=LC (13 live) 0ms 256 bytes (pipelined: 5) (range: bytes=0-)
Mar 31, 2019 08:55:10.068 [0x7f381d7fa700] DEBUG - Request: [127.0.0.1:57482 (Loopback)] PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress/streamDetail?index=0&id=1&codec=h264&type=video&bitrate=1095352&profile=High&language=eng&width=720&height=384&interlaced=0&sar=3453:3494&level=31&frameRate=23.976&disp_default=1 (13 live) Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:10.068 [0x7f387c88d700] DEBUG - Completed: [127.0.0.1:57482] 206 PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress/streamDetail?index=0&id=1&codec=h264&type=video&bitrate=1095352&profile=High&language=eng&width=720&height=384&interlaced=0&sar=3453:3494&level=31&frameRate=23.976&disp_default=1 (13 live) 0ms 256 bytes (pipelined: 6) (range: bytes=0-)
Mar 31, 2019 08:55:10.068 [0x7f383e7fc700] DEBUG - Request: [127.0.0.1:57482 (Loopback)] PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress/streamDetail?index=1&id=2&codec=aac&type=audio&profile=LC&language=eng&channels=2&layout=stereo&sampleRate=48000&disp_default=1 (13 live) Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:10.069 [0x7f387c88d700] DEBUG - Completed: [127.0.0.1:57482] 206 PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress/streamDetail?index=1&id=2&codec=aac&type=audio&profile=LC&language=eng&channels=2&layout=stereo&sampleRate=48000&disp_default=1 (13 live) 0ms 256 bytes (pipelined: 7) (range: bytes=0-)
Mar 31, 2019 08:55:10.069 [0x7f383f7fe700] DEBUG - Request: [127.0.0.1:57482 (Loopback)] PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress?duration=6005.035000 (13 live) Signed-in Token (ninja888plex)
Mar 31, 2019 08:55:10.070 [0x7f383effd700] DEBUG - Started session successfully: A93389EA-9DE8-4C94-B8A9-521CF77F944C
Mar 31, 2019 08:55:10.070 [0x7f3877fff700] DEBUG - Completed: [127.0.0.1:57482] 204 PUT /video/:/transcode/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/4dcfbbb3-b3f8-403c-8169-74e1b078297c/progress?duration=6005.035000 (13 live) 0ms 203 bytes (pipelined: 8) (range: bytes=0-)
Mar 31, 2019 08:55:10.070 [0x7f383effd700] DEBUG - HLS: Building an M3U8 for 6006 total seconds with 8 seconds/segment, target duration of 8.
Mar 31, 2019 08:55:10.071 [0x7f387c88d700] DEBUG - Completed: [XXXXXXXXX1:55901] 200 GET /video/:/transcode/universal/session/A93389EA-9DE8-4C94-B8A9-521CF77F944C/base/index.m3u8 (13 live) TLS 2691ms 20630 bytes (pipelined: 1)
This line:
Mar 31, 2019 08:52:08.948 [0x7f387e090700] INFO - Processor Common KVM processor
May or may not have impact. I say this because last night I assisted with two systems. Xeon E3-1245 v3 and E3-1246 v3.
Both professed to have QSV and was visible as /dev/dri/renderD128 however, even when PMS tried to engage hardware transcoding, the onboard ASIC was not capable.
Looking for those CPUs in the NAS guide confirmed what I thought my previous testing had found. The HW transcoding ASIC in those chips was first-generation in a “v3” xeon. Plex supports second generation HW transcoding ASICs and above.
If your system is one of these processors, the anomaly is now explained.
Is it possible to have the processor fully visible (transparent) to the VM? In this mode, the processes running in the VM have no knowledge of their VM status . CPUID, specfiically /proc/cpuinfo which returns the true processor registers, will then return the correct info to PMS.
I’ll see if there is a way of passing the actual host CPU through to the VM but I’m now not convinced this has anything to do with virtualisation …
The VM we’ve been discussing so far is hosted on an Intel NUC8I5BEH (Intel® Core™ i5-8259U Processor) which does have QSV. I’ve just checked on my other NUC7PJYH (Intel Pentium Silver J5005 Processor) which also has QSV and runs Plex on Barebones Ubuntu Cosmic 18.10 and I can also see occurrences of the same warnings in the logs…
Other than these warnings, I have nothing to believe it is not hardware transcoding - Both servers show very little CPU usage when transcoding and Plex dashboard shows “(hw)” next to decoding / encoding.
In parallel, I may try an earlier version and see if the same warning is output.
I’ve uploaded the physical host (ruling out virtualisation but on a different host) Plex Media Server.log to the same location as earlier … The same warning occurs on that box…
Next I’ll try and roll the physical Plex server back to an older version, if I can find the older files:)
I’ve removed the reference to Proxmox now from this thread title since the issue occurs on both a Proxmox VM and on a barebones install of Ubuntu 18.10 Desktop on a NUC7PJYH (Intel Pentium Silver J5005)… Whilst currently the Intel website doesn’t specifically say this CPU does / does not support Intel QSV, it has done before and hardware transcoding also seemingly works on this CPU (very low utilisation and Plex web dashboard image as per first post in this thread).
Plex 1.14.1.5488-cc260c476 on the barebones Ubuntu 18.10 on the NUC7PJYH outputs the following in the logs when I force a transcode of a 1080p H264/AAC -> 480p H264:
Mar 31, 2019 15:36:02.382 [0x7ff7603f7700] DEBUG - Codecs: testing h264_vaapi (encoder)
Mar 31, 2019 15:36:02.383 [0x7ff7603f7700] DEBUG - Codecs: hardware transcoding: testing API vaapi
The newer 1.15.1.791-8bec0f76c version gives the following output to the log for the same test:
Mar 31, 2019 14:49:01.736 [0x7fecc7fff700] DEBUG - Streaming Resource: Determining preferred transcode encoders through transcode only decision.
Mar 31, 2019 14:49:01.736 [0x7fecc7fff700] DEBUG - Codecs: testing h264_qsv (encoder)
Mar 31, 2019 14:49:01.736 [0x7fecc7fff700] WARN - Failed to find encoder 'h264_qsv'
Mar 31, 2019 14:49:01.736 [0x7fecc7fff700] DEBUG - Codecs: testing h264_vaapi (encoder)
Mar 31, 2019 14:49:01.736 [0x7fecc7fff700] DEBUG - Codecs: hardware transcoding: testing API vaapi
So, it looks like this new “h264_qsv” encoder was introduced somewhere in 1.15.x and causes the warning, likely because of the file not being there on the plex.tv side to download…
On both versions it looks like the hardware transcode is done via “h264_vaapi” rather than this new “h264_qsv” codec…
Hi @ChuckPa - Were the devs able to comment on what this ‘h264_qsv’ codec is that was introduced in 1.15.x and why it is any different to the ‘h264_vaapi’ codec which seemed to work fine for hardware transcoding from my Intel CPUs in 1.14.x+ ?
isn’t quicksync (qsv) for windows, and vaapi for linux ?
based on this @ https://wiki.ubuntu.com/IntelQuickSyncVideo
I think it is safe to ignore the h264_qsv error, it appears to be an older kind of hardware decoding.
it appears that your HA is working properly, otherwise your cpu would be bogged down and you would probably have those annoying buffering issues going on.
VAAPI uses the Quick Sync Video ASIC in the chip to provide the hardware transcoding.
DXVA / DXVA2 (Windows) and VAAPI (Linux) are the two API interfaces.
Thanks guys. If the server should (and does) call h264_vaapi then there’s no reason why it should have to find/download/call h264_qsv.
As such, looks like a cosmetic bug in the server transcoder but one worth fixing since it gives the impression from the logs that it is not hardware transcoding, when actually it is.
Im sure it will be addressed. There has been a lot of changes recently. Bound to be some minor breakage.
Devs monitor the forums but here in the Linux section, a couple team members help out when I submit bug reports.
As for the two you mention above,
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
