Running a hardware transcode of a 1080p 10bit HEVC file to 720p h264 results in vertical stripes of smeared color in video on Synology DS918+ running Plex Server 1.11.1.4760 (64bit)
This appears to be a problem with the resize - as 1080p HEVC-> 1080p h264 works fine.
Turning off hardware transcoding fixes the color issue on resize - (but with a substantial CPU hit)
Here is a screen grab showing the problem - in particularly visable around the red car in the centre. This happens on every HEVC video I have if it is resized during the transcode - surely someone else must be seeing this???
It’s likely because hardware transcoding results in lower quality than the software encoding.
Hardware transcoding is not causing this issue - it’s incorrect parameters for the resize. 1080p -> 1080p does not show this problem. The resize is not respecting the memory layout of the source image - and distorting the chroma components (if you look at the image closely - you’ll see that the intensity is about right - indeed, if you convert the screen grab to grayscale, it looks fine).
I’m pretty sure something is messed up with the YUV format at one end of the resize. (either giving the encoder or the resize the wrong format) - and ought to be trivial to fix.
I’ve found a workaround for the issue - Emby Media Server manages to do hardware transcoding and resizing of HEVC files without distorting the UV chroma channels in the video. This is definitely not a limitation of hardware, but a bug in the configuration of FFMPEG in Plex.
A Plex Pass supposedly gets you support and hardware transcoding. Both appear to be broken from my experience in the last two months. Unless something improves - I’ll be switching at the end of the month.
[EDIT]
Ended up not switching, and Plex support stepped up :). This appears to be an issue with the pixel format conversion during the resize. Until this can be fixed properly in code, I’ve managed to work around the issue on a Synology DS918+ by stripping out the format conversion arguments - see https://forums.plex.tv/discussion/305999/color-corruption-on-resize-when-hw-transcoding-hevc-content-to-h264-4k-subs-synology-ds918-nas#latest
@jaB00M said:
I’ve found a workaround for the issue - Emby Media Server manages to do hardware transcoding and resizing of HEVC files without distorting the UV chroma channels in the video. This is definitely not a limitation of hardware, but a bug in the configuration of FFMPEG in Plex.A Plex Pass supposedly gets you support and hardware transcoding. Both appear to be broken from my experience in the last two months. Unless something improves - I’ll be switching at the end of the month.
Do you have any experience with subtitle support, without transcoding, in emby? I tried the sever on my synology, last time the file crapper didn’t recon all my files and so i stoped the try. So, i am really pissed from plex in the last time and considering switch over, too. I am willing to invest the time to set it up if i get the benefit. So, would you share your experience with emby, please.
So I’ve only been running Emby a day - but the subtitle support seems to be the same as Plex. It falls back to baking in and transcoding if the subtitles are image based (ie VOBSUB) - but sends text based subtitles without transcoding.
I have an issue with baked in subtitles on 4K videos with both Plex and Emby - the server just won’t transcode quickly enough - but is not limited by CPU. Guessing this too is an FFMPEG thing, and the filter being used to add them is doing something less than great with frame buffers. I’ve not looked indepth at how it works, but my first guess would be that adding subtitles requires each frame to roundtrip from GPU memory to system memory and back - which probably introduces too much delay in the transcoding pipeline to keep up/not run out of buffers (and 4K buffers are big).
Thx, for you answer. I set up an emby server today, too. It runs parallel to my PMS. It seems that the subtitle support is a little bit better then in plex. I checked on the web app only, but i got one transcode and one direct play on emby vs. two transcodes on plex. (ASS in mkv) The customizability seems better then in plex but the HW transcode produces artifacts what i’ve seen in plex only during the beta phase.
Do you’ve any experience with the frontend apps? My preferred frontend device is a shield and i use it with kodi (PlexKodiConnect) because the native app can’t play ass/ssa native and you can’t change subtitle colors.
I’ve been using Kodi on an Intel NUC - with the EmbyCon and Plex for Kodi addons. Emby has another addon that isn’t in the official Kodi repo, ‘Emby for Kodi Sync’ - which I think works in a very similar way to PlexKodiConnect. Both of these mess with the Kodi DB though, so almost certainly won’t play nicely together.
So, I made a new test with the web app. Both lack the support of pgs subtitles and start to transcode. The burning in is better done by plex, because emby places the subtitle in a black frame. Both stalls with hw transcode (1080P with 27 Mbit h264) and both do it fine with software transcode.
Interestingly - forcing subtitle burn in fixes the UV color smearing issue I was seeing on hardware transcodes in Plex - presumably because it forces the colour space to be converted to RGB when applying the subtitle overlay filter. It can’t keep up for real time - so not a solution, but demonstrates that the UV corruption I’m seeing isn’t an issue with the hardware encoding itself.
I think the only solution to the HW transcoded subtitle burn in performance is to either do the overlay merge on the GPU (I’ve no idea if this is possible - just looking at the VAAPI docs now…) or maybe the performance hit from roundtripping the frames can be mitigated by doing a software decode and overlay merge, then a hardware encode? The ffmpeg subtitle filter I assume Plex is using is software only.
Another avenue could be to look at running a seperate encode and decode process of ffmpeg. I’m pretty sure the hardware is capable of running this - even with the round tripping, but must be hitting buffering issues somewhere in the pipeline.
I am encountering the same issue on my Synology DS218+, with vertical bars of color corruption appearing :
(720p 4 Mbps)
The movie is a 1080p HEVC 10bit file. The color corruption seems to only appear when reducing resolution of an HEVC10 file.
Using PMS version 1.13.0.5003, so the issue is still present with the latest version
