Improve Plex Transcoding image quality

[Whattteva]

I think you'd want to look for the ones that have "QuickSync" listed on the specification list for Intel.
AMD also has a similar feature, but they call it "Video Coding Engine" or more commonly shortened as VCE.
I think, depending on the transcoder support, you could also use OpenCL, which I think both vendors now are starting to support along with several FPGA vendors as well.

 

[camilo suarez]

well.. in ark intel, my cpu appears to have quicksync

http://ark.intel.com/products/77773/Intel-Pentium-Processor-G3220-3M-Cache-3_00-GHz

 

[Whattteva]

Then, it should chug through encoding pretty fast. You do have to configure the transcoder to use that hardware support though.

 

[cyberjock]

Honestly, I have a Xeon E3-1230v2 and the v2 or v3 version is basically a bucketload of processing power. That's what I recommend when people want to do Plex.

 

[cyberjock]

quicksync is not supported on FreeNAS. So that feature gains you nothing. ;)

 

[no_connection]

Check the plex log for encoding speed. Is shows how much faster then realtime(or slower) that it encodes at.

 

[camilo suarez]

My guess is CPU bound. We tell people not to use the Pentium CPUs when you want to transcode, which is exactly what you are doing. To boot you are transcoding to 1080p and that's going to put serious hurt on the CPU.

It is possible it's the wireless.

CPU bound is easy to diagnose.. go to the command line and look at # top while using the machine. If its still skipping and CPU usage is only 40% then you know that's not the problem. Do look to see if your using a codec that is single threaded (yes, some do exist and you can't fix this except to convert the original to an alternate).

this are the readings that im getting, i guess im maxing out the CPU. but im getting 200% usage even with 4mb @ 720p.

 

[cyberjock]

That sounds like it's cpu bound then. :(

 

[SirMaster]

Unfortunately looking at the CPU usage % is not going to tell the whole story since the Plex New Transcoder is configured to encode ahead of the streaming and cache the result to disk to stream from. So it will often use up as much CPU as is available and then finish the encode well before the video is done streaming so even if it were encoding slower it would still be able to keep up.

Plex is definitely tuned for a lowest common denominator setup to use low CPU usage for people with slower dual-core CPUs and there is a lot of additional quality you can get out of it when you tweak the encoder. For example Plex by default is only using the "veryfast" x264 preset which quite honestly is not great image quality-wise at lower bitrates like 3-4mbit though of course it is fast which is the point.

I've set mine up so that when it transcodes it uses up about 750% of my 8 threaded Xeon and just barely stays ahead of the real-time stream. It has vastly improved image quality. I didn't do it by modifying the xml configs though as I found that to be too limiting still. I did it by modifying the encoding parameters as they are passed into the transcoder itself.

Start by switching the "veryfast" preset up the scale to slower presets until your stream can no longer keep up. Unfortunately I don't think you can go very far past veryfast with only a dual-core but I bet you can go up at least 1 notch which will still make a noticeable difference if you are picky about image quality.

 

[camilo suarez]

well. i was experiencing the freezing every 20 seconds in the old version (the version before the last update) yesterday testing again with pacific rim that was the same movie that was freezing, the freezing its almost gone, just 1 freeze of ~500ms for about every hour. so i think the last update improved somehow the transcoder performance, the testing that i did yesterday was @maximun quality in the settings of the android app (the movie its a 20gb size).

i guess im still CPU limited but the performance improved since the last update.

 

[cyberjock]

Unfortunately looking at the CPU usage % is not going to tell the whole story since the Plex New Transcoder is configured to encode ahead of the streaming and cache the result to disk to stream from. So it will often use up as much CPU as is available and then finish the encode well before the video is done streaming so even if it were encoding slower it would still be able to keep up.

Plex is definitely tuned for a lowest common denominator setup to use low CPU usage for people with slower dual-core CPUs and there is a lot of additional quality you can get out of it when you tweak the encoder. For example Plex by default is only using the "veryfast" x264 preset which quite honestly is not great image quality-wise at lower bitrates like 3-4mbit though of course it is fast which is the point.

Thanks for validating my comment above.

Look at his picture closely. He sits at 100% CPU non-stop while streaming. If he weren't CPU bound it would go to 100% until the buffer filled and then it would be in spurts. The fact that he sat at 100% for almost 30 minutes straight is solid, irrefutable evidence that he IS CPU bound. When you watch my server transcode it goes to 100% for about 20 seconds, then fluctuates from second to second as Plex refills the buffer every few seconds. But, it does NOT bury the needle at 100% CPU usage non-stop.

And since Plex uses the already fast x264 preset you've only provided more evidence that not only is he CPU bound but he can't easily change his options to something that is more CPU friendly.

So thanks for validating me. :)

The user still needs a new CPU. There's a reason why we tell people "if you want to transcode, use encryption, or use high compression you should get a Xeon or at least an i3". Because its a fact based on dozens and dozens of users that have learned this lesson the hard way.

 

[camilo suarez]

Thanks for your help guys :)

 

[SirMaster]

Yes, by default (or at least the default on my Plex install) was that it would "bury" the needle on transcoding for 60 seconds and then throttle the transcoder. This is even configurable in the Plex Web GUI.

Well he could make it a lot faster yet, "veryfast" is 3rd from the bottom, there is "superfast" and "ultrafast" below, but those would be even worse quality and he wants better.

I think he should try "faster", and then "fast" to at least see if his CPU can keep up or not. I made it all the way to "slow" which is 4 higher than "veryfast" and my CPU can still keep up with a 1080p transcode but yes my CPU is an 8-thread Xeon and his is a 2-thread G3220.

If he goes up to "faster" and the encoding cant keep up then yeah there is nothing he can do to improve quality noticeably of his transcodes with that current CPU.

 

[camilo suarez]

Sir master, how do i change that settings? Thanks for your help and information :)

 

[SirMaster]

Here is the way I handle mine on Linux, but it should work the same on FreeNAS I would think.

First you need to find the "Plex New Transcoder" binary. Mine was in "/usr/lib/plexmediaserver/Resources"

Then I renamed the "Plex New Transcoder" to just "Transcoder"

Then I made a new empty file called "Plex New Transcoder" (same as the name of the original binary)

Inside this file I put this script:

Code:

#!/bin/bash
pkill Transcoder

params=( "$@" )

for ((i=0; i<${#params[@]}; i++));
do

    if [[ ${params[$i]} = "veryfast" ]]
        then params[$i]="slow"
    fi

done

/usr/lib/plexmediaserver/Resources/Transcoder "${params[@]}"
pkill Transcoder

So what it does it intercept the parameters that were going to the "New Plex Transcoder" and then modifies the "veryslow" preset to "slow" and then passes the new parameters into the actual transcoder now called "Transcoder"

You will have to modify the path at the end of the script to put where your binary is really located and use "faster" instead of "slow".

And don't forget to make the new script executable (chmod +x) and set the permissions to match whatever they were for the original encoder binary.

Hope it makes sense.