DSM Version: 6.2.2-24922
Server Version: 1.15.6.1079
Player Version: Web 3.100.1
I’ve recently begun adding 10-bit H.265/HEVC content into my library but have noticed very poor video quality while using hardware acceleration for output resolutions under 1080P. I’m aware that the CPU in the DS918+ (Celeron J3455) is one of the first generations to support hardware-accelerated 10-bit HEVC decoding and so is likely to leave something to be desired in terms of quality, but what I’m experiencing is still a little baffling to me and I’m wondering if Plex might be able to mitigate it in some manner.
Below are some examples (and the related log entries) of the quality issues I’ve been seeing using jellyfish-10-mbps-hd-hevc-10bit.mkv from http://jell.yfish.us/. The first configuration renders well, but the lower resolution videos from the same source show some kind of vertical striation on the jellyfish tentacles.
10-bit H.265 1080P source to “8 mbps, 1080p HD” H.264:
Streaming Resource: Reached Decision id=23627 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=38983 part=(id=60231 decision=transcode container=mp4 protocol=dash streams=(Video=(id=156707 decision=transcode bitrate=7540 encoder=h264_vaapi width=1920 height=1080))))
10-bit H.265 1080P source to “4 mbps, 720p HD” H.264:
Streaming Resource: Reached Decision id=23627 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=38983 part=(id=60231 decision=transcode container=mp4 protocol=dash streams=(Video=(id=156707 decision=transcode bitrate=3807 encoder=h264_vaapi width=1280 height=720))))
10-bit H.265 1080P source to “2 mbps, 720p HD” H.264:
Streaming Resource: Reached Decision id=23627 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=38983 part=(id=60231 decision=transcode container=mp4 protocol=dash streams=(Video=(id=156707 decision=transcode bitrate=1889 encoder=h264_vaapi width=720 height=406))))
8-bit H.264 1080P source to “2 mbps, 720p HD” H.264:
Streaming Resource: Reached Decision id=23629 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=38985 part=(id=60233 decision=transcode container=mp4 protocol=dash streams=(Video=(id=156709 decision=transcode bitrate=1889 encoder=h264_vaapi width=720 height=406))))
The last capture is from the H.264 version (jellyfish-10-mbps-hd-h264.mkv) of the same video, which doesn’t produce the same issues at low resolution.
As mentioned, I’m not surprised that there could be quality issues with Apollo Lake’s H.265 decoder, especially at resolutions below the common UHD use case, but I don’t quite understand why it’s only sometimes an issue when the source to decode is always 1080P, and the encoder in use is the mature H.264 encoder. The H.265 hardware decoder processes the same 1080P source file each time (and seems able to accomplish it without issue as seen in the 1080P example)… but issues arise when the H.264 encoder is set to target a resolution below 1080P, even though that same encoder can be demonstrated producing much better quality low-resolution video from another source of similar quality. What am I missing here?
My confusion probably comes from a misunderstanding of Plex’s transcoding pipeline. I was under the impression that Plex’s transcoding engine supported hardware decoding and encoding as separate steps, allowing it to use either hardware or software routines for those steps in any combination, and that given the same source file, a particular decoder would hand over the same information to be encoded to the required encoder. I am assuming the encoder receives the source data at its original resolution, and that the resolution resizing isn’t happening in the decoder… if the decoder is doing the resizing, I may have just answered my own question.
If that is the case, might there be some way to disable hardware decoding for certain codecs and resolutions, or have the encoder handle resizing instead of the decoder?
