This problem is present since ages.
Example:
This happens only in dark / flashing scenes and not in all frames:
It happens only if I hardware-transcode through my Intel iGPU (UHD 630 / UHD P630) and not if I use software-transcoding. I was not able to test it with an Nvidia GPU, but I think its only related to Intel.
Tested on:
Unraid server with Xeon E-2146G, i3-8100 and i3-9350K
Recent Plex Docker Container
Recent Plex Windows Client and Recent Samsung TV App
Test file for the devs (2x 4 seconds without audio):
Split and audio/chapter/subtitle removal was done with MKVToolNix.
Welcome to VC-1. <—the most vile thing ever invented.
I don’t have any of it - 'cause I don’t have anything that can Direct Play it. As far as I know. It all gets re-coded to something I can Direct Play because I don’t want to go through what you’re going through.
VC-1 is a Single Threaded Operation.
If you had 32 cores - VC-1 could only use 1 of them.
If you don’t think that’ll really mess up your GPU’s day - think again.
You already found the answer.
Use the CPU. It obviously has more of what it takes to deal with VC-1.
Since the transcoder has to work - why not encode a working version once - instead of having to create one every time you watch it?
That’s my motto.
Simple answer why I don’t:
I’m from a country with high energy costs.
If there would be an option to transcode only VC1 with my CPU, I would use it, but I would not transcode all my content with it.
I don’t like to touch my original rips. And as not all my clients need transcoding it does not really make sense to transcode all VC1 movies. I never counted them, but it should be between 500 and 1000 movies. A never ending transcode job. ^^
At some point you’ll resign and convert it to something sensible. Just get it done and get this headache out of your life. 
I’m getting a headache while thinking about the huge electricity bill caused of 24/7 transcoding for several months. This is nothing which is transcoded in a few days. And of course I need my server doing other things, too. I can’t block it only for transcoding, so it would even take longer.
On-topic:
As far I understood this discussion its related to the driver which Plex is using, so why does Plex not use a different driver for VC1 or solve this bug?
Plex uses ffmpegs libavcodec, correct? Maybe I should try to transcode the clip with ffmpeg and post an issue at ffmpeg.org… Is there a way to find out which options Plex is using to transcode the stream?
Plex is using whatever driver is installed on your PC/server. If it can be solved in ffmpeg it would have to be reported to them.
I’m sorry, but the only real solution is getting rid of the VC-1 files. It’s not the answer you want, but it is the answer that will be guaranteed to fix your issue in the foreseeable future. If you’d rather want to hit your head into this wall instead of paying marginally more on power to convert in the short term, that’s on you. It’s on the scale of turning on an additional light bulb or two in your house, probably.
I’m using the official docker container, so its nothing I’m able to control.
The question is, did anyone from the devs ever checked the problem? Maybe its an option which needs to be changed/enhanced.
I transcoded the sample file with the following ffmpeg container and the output is flawless:
docker run --device /dev/dri:/dev/dri -v $(pwd):$(pwd) -w $(pwd) jrottenberg/ffmpeg:vaapi -y -hwaccel vaapi -hwaccel_output_format vaapi -i input.mkv -vcodec vc1_vaapi -acodec copy -b:v 10000K -c:v h264_vaapi output.mp4
Result:
https://www.dropbox.com/s/umiy7na2d6kxv4a/2021-04-09%2015-44-07.mkv?dl=0
MediaInfo
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 8 s 50 ms
Bit rate mode : Variable
Bit rate : 9 745 kb/s
Maximum bit rate : 20.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.196
Stream size : 9.35 MiB (100%)
Language : English
Codec configuration box : avcC
This is what was inside the Plex transcoding dir:
https://www.dropbox.com/s/ftsiqvsu8u0fsi6/chunk6.mkv?dl=0
(I used “cat” to create the video file with the “header” and “chunk-xxx” file)
MediaInfo
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 2 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 2 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1 h 58 min
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (23976/1000) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : Lavc58.52.100 h264_vaapi
Language : English
Default : Yes
Forced : No
The problem is there is a bug in Intel’s drivers on Linux when it comes to VC-1 hardware decoding. This was fixed at one point years ago but then Intel put out a new driver re-breaking it. The problem is the new driver is necessary (I don’t recall the details but likely due to hardware support) so we can’t go back.
The same issue doesn’t exist on Windows. Given the persistence of this, either Intel doesn’t care about VC-1 or Linux (or both).
Plex is touching them in unpleasant ways every time a VC-1 items vomits all over the place.
I have 6500+ Movies in the P’Verse - maybe a Dozen had VC-1 (thank the maker).
I’m already doing that.
The Server runs 24/7 - along with Handbrake - 'cause I’m creating material that Direct Plays on every device/client in the P’Verse. If a VC-1 item tries to enter the establishment, It’s stripped, frisked and redressed before it can take one step on the dance floor. Them’s is the rulez.
I can’t believe you’re paying more for Electricity than I am. I’ve been paying $300 Electric Bills all Winter and we heat with Gas. If you do pay more - I feel your pain - but your GPU won’t do a very good job of transcoding VC-1. Unfortunately.
I checked it now. 529 movies use the VC1 codec:
Which command are you using to convert them? I fear quality loss and breaking my MKVs as they do all contain manually named Subtitles (forced, languages etc).
That’s an amazing number of VC-1 videos. I think I have 10, none after 2008.
It’s hard to recommend video encoding settings, because it depends on each individual’s quality tolerances. And it leads to a lot of arguing accordingly. But for your average VC-1 encoded video, you could almost certainly use FFMPEG/Handbrake to encode the video to either H264 (8-bit!) or 10-bit H265, constant quality at RF20, and just pass through the existing audio. [Note: you could consider re-encoding that audio track to AC3, because it’s possibly being transcoded along with the video, as many Samsung’s don’t support DTS or TrueHD].
Unfortunately any quality software-based encode is very slow, especially for H265. H264 will be much faster, but the equivalent file size will be significantly larger at similar quality. The file size also would be variable when using RF, and would depend on the original video; grainy film encodes would be significantly larger than “clean” ones. But this would be a slow process no matter what.
No matter what, you’d need to encode some sample chapters of various and review them yourself. Only you can tell what encode is right for you, and you’d want to confirm that they direct play on the devices you have.
Do you just need it fixed for one TV? You could consider adding an Nvidia Shield to it. It will direct play the VC-1 files, as well as the audio tracks. It’s not cheap, but could be an easier solution than manually encoding all those files. But you’d still have the problem on phone/tablet/etc.
I think it depends on the amount of Blu-Rays you have ripped. My collection contains 99% Blu-Rays and 1% DVDs and 4Ks.
I’m not tolerant. They should look like the original. ^^
This would cause much more transcoding as much more clients support H264 instead of H265.
I already add AC3 to all movies with DTS audio. But I keep the original audio track., too. Nobody knows what the future holds.
I have several Android Devices and TVs not supporting VC1. Some TVs support VC1, but not the high bitrate. Having an additional device does not add any comfort. I’m now able to use one TV remote and it works flawlessly except of some VC1 movies. And finally I think it would be better to save the money and spend it for the next TV generation.
Today I tried software transcoding while viewing a VC1 movie. It worked good while power consumption was really bad (100W vs 30W), but for the small amount of time it would be acceptable. But as I’m not able to disable hardware-transcoding only for VC1 movies, this would overload my server depending on the amount of parallel transcodings.
Its really sad not being able to choose which codec uses which method.
Maybe I will transcode them to H264 but keep the original VC1, too. I need to think about this.
Don’t quote me on this (ok quote me if necessary), but I am pretty sure that if you have both a VC-1 and H264 copy of a movie in the same library with the same resolution (1080p), Plex will automatically choose the codec that will direct play on that device.
Hmmm, I might have time to test this tonight. If you don’t mind the extra space being used, it could be a workable solution for you.
BTW, you should consider a blind test, watching an original file and a well re-encoded file, to see if you can really tell the difference. Maybe pick 10 movies and see how it goes. No sarcasm intended here, I’ve found it’s very hard to tell when done right. (I still generally use originals whenever possible)
No luck. I tested a movie with both VC-1 and H264 encodes, and Plex defaulted to playing H264 everywhere, including my Shield that can direct-play VC-1. I can manually switch to the VC-1 copy on the Shield by using “Play Version”, and it direct-plays of course. So you’d still have the option of the original when you want to see it.
If that’s a workable option for you, perhaps it could be considered. I don’t think there’s any perfect solution for you, so long as there are bugs with the VC-1 hardware acceleration on Linux.
Edit: I take it back, upon further review it defaults to VC-1 on Plex for Windows, but not on the Shield. Go figure. But on the bright side, it doesn’t seem to default to a transcode on any client.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
@mgutt I am necromancing this dead thread in case you never found a resolution. The macroblocking artifacts is a VC-1 regression with the Linux Intel iHD drivers.
Set PMS to use VaapiDriver=“i965” instead of the implicit default which is iHD .
This variable can be added/modifed by:
/var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server/Preferences.xml
or you can run the following command on the host
curl http://127.0.0.1:32400/:/prefs/set?VaapiDriver="i965"&X-Plex-Token=REDACTEDCaveat: The VaapiDriver=“i965” variable does not work with Intel Core 10th Gen CPUs and newer.
@Achilles - Thanks for this update. However, I tried the suggested modification to Preferences.xml (added VaapiDriver=“i965”) and after restarting plexmediaserver, the web UI would not connect even though the service was running. I reverted the change and everything is back to normal.
My distro is Ubuntu 20.04.3 LTS x64, CPU is Intel Core i7-9700, and Mesa Intel UHD Graphics 630 (CFL GT2).
I haven’t seen that with the varies Coffee Lake CPUs I have used and tested. Are you sure you added the variable correctly with proper format? Changing the VAAPIDriver should not prevent the WebUI from starting unless it doesn’t accept the preferences.xml after you modified it.
