The DS920+ has a Gemini Lake CPU.
See this post:
What about Xeon (E3-1246 v3)? I’ve been away for a bit and just getting caught up with the thread, wondering which version to try rolling up/down to.
For those with GeminiLake problem, 1.31.3.6999 as it predates the regression.
The Xeon quick sync is OK . It is only limited by its generation ( Haswell )
Can you elaborate, or point me to more info on the limitation of Haswell?
Thanks!
Look at ark.intel.com
Next search for your specific CPU.
When you get to the built in features, you can dig further.
I’ve a PC with an i7-4790K, which is Haswell.
Haswell has HD4600 graphics. Using Quick Sync, it will decode H.264, VC-1, & MPEG2 video, and encode H.264 video.
Decoding HEVC/H.265 will use the CPU, not the Quick Sync graphics. The CPU is not strong enough to transcode & tonemap 4K HDR video.
A Kaby Lake processor is necessary for hardware accelerated transcoding and tone mapping of 4K HDR video (Ref: HDR to SDR Tone Mapping). For Core CPUs, Kaby Lake is 7th gen (7xxx). Not sure how that aligns with Xeon model numbers.
The processor datasheet (via ark.intel.com) has additional details on the capabilities of the CPU, including Quick Sync graphics. For Core CPUs, it is usually in Datasheet, Vol. 1, in the Processor Graphics section. I’m not sure about Xeon CPUs, I’ve never looked at their datasheets.
1 Like
Thanks. The specs list Quick Sync as Yes but I’m not sure what features to dig into.
As FordGuy stated, you’re good up through and inclusive of H.264
Haswell will not do HEVC (decode or encode) in hardware
Thanks for the clarification. Somehow I overlooked his post yesterday but now that I’ve read it I’m sorted.
I was already trying to justify refreshing my entire server hardware in the next few months. This gives me more of an excuse.
Hello,
Tried the 1.32.5.7328 with an Apollo Lake CPU (using a DS918+) on docker (linuxserver.io).
I play an HEVC video to try transcoding, and there is still a lot of buffering, despite the CPU at “normal” levels of usage (same a 6999 for the same video file).
If i go back to 6999 , transcoding works like a charm. This is still not fixed ? Or something must be changed in configuration or anything else ?
Anyone else has the same issue?
Cannot tell what’s happening without logs.
Sorry
Oops Sorry, here are some logs for a play i just tried with latest version.
Plex Media Server.log (1.4 MB)
You are using Chrome, transcoding, and have subtitles enabled. Plex is using hardware accelerated transcoding.
Chrome has limited subtitle support. As a result, Plex is burning the subtitles into the video stream.
Subtitle burning uses the CPU and the J3455 in the DS918+ simply is not strong enough to burn subtitles in real time. This is why you experience buffering.
If you play the media without subtitles, it will most likely play without buffering.
Log file info:
Plex Media Decision Engine. Notice the lines that mention subtitle burning.
Jul 20, 2023 22:39:18.112 [140335281843000] DEBUG - [Req#bf/Transcode] MDE: E1 - Un départ et des amis: media must be transcoded in order to use the dash protocol
Jul 20, 2023 22:39:18.112 [140335281843000] DEBUG - [Req#bf/Transcode] MDE: E1 - Un départ et des amis: selected subtitle cannot be converted to a compatible format, burning into video stream
Jul 20, 2023 22:39:18.112 [140335281843000] DEBUG - [Req#bf/Transcode] MDE: E1 - Un départ et des amis: avoiding video remux due to burned subtitle stream
Jul 20, 2023 22:39:18.112 [140335281843000] DEBUG - [Req#bf/Transcode] MDE: E1 - Un départ et des amis: no remuxable profile found, so video stream will be transcoded
Jul 20, 2023 22:39:18.112 [140335281843000] DEBUG - [Req#bf/Transcode] MDE: Cannot direct stream video stream due to profile or setting limitations
Plex is transcoding the video to H.264, Audio to AAC, and burning in the subtitles.
Jul 20, 2023 22:39:18.145 [140335281843000] DEBUG - [Req#bf/Transcode] Streaming Resource: Reached Decision id=32888 codes=(General=1001,Direct play not available; Conversion OK. Direct Play=3000,App cannot direct play this item. Direct play is disabled. Transcode=1001,Direct play not available; Conversion OK.) media=(id=34132 part=(id=36094 decision=transcode container=mp4 protocol=dash streams=(Video=(id=103729 decision=transcode bitrate=2147483647 encoder=h264_vaapi width=1920 height=1080) Audio=(id=103730 decision=transcode bitrate=256 encoder=aac channels=2 rate=48000) Subtitle=(id=103732 decision=burn languageCode=fra location=embedded))))
Plex is using hardware accelerated transcoding (vaapi).
Jul 20, 2023 22:39:18.350 [140335281843000] DEBUG - [Req#d6/Transcode] TPU: hardware transcoding: final decoder: vaapi, final encoder: vaapi
Hi @FordGuy61 ,
Thanks for your reply but I think you missed the part in my first post where I said it works perfectly fine with version 6999, the last version before it broke hw transcoding.
I use Chrome only to test transcoding.
I’m really confused now. Is it possible for Plex to fallback to software transcodes when encountering HEVC? If so I can’t get this to work with the AndroidTV client on my older Sony TV, it just errors out. The same files will play in the Android app on my Pixel and also seem to be transcoding fine.
How is the progress on returning HW transcoding to the GeminiLake DS920+ system?
As of this main release version, we are now there. I have the DS720+ which runs the same processor, the J4125.
1.32.5.7328 does not have the fix for Gemini Lake (J4xxx) CPUs.
Really? I thought that engineer build Version 1.32.5.7145 had all the fixes?
Was that just for the Apollo lake chips?
Not great then that we are still awaiting a fix for this.
On my DS918+ (J3455 apollo lake),1.32.5.7349 is still buffer hell when transcoding.
Rollng back to 6999 works perfectly fine for the same file.
Do I have options to test in preferences or anything ? It’s kinda concerning at this point.
