We all know Netflix. And we all know that Netflix handles streaming at the very best. What most of us didn’t knew is that Netflix nearly never uses 8 Mbps for 1920x1080. Just because it’s waste of storage space and bandwidth.
Problem: Those who really should read the blog post won’t understand it because it’s too complex. In short: We never get a useful Optimizer feature.
The best thing is to optimize manually, using mkvtoolnix and x264 (can be fully automatic).
@an3k said:
We all know Netflix. And we all know that Netflix handles streaming at the very best. What most of us didn’t knew is that Netflix nearly never uses 8 Mbps for 1920x1080. Just because it’s waste of storage space and bandwidth.Problem: Those who really should read the blog post won’t understand it because it’s too complex. In short: We never get a useful Optimizer feature.
The best thing is to optimize manually, using mkvtoolnix and x264 (can be fully automatic).
I think we can all agree netflix doesn’t stream near bluray quality. Can’t say that’s the very best.
You mix two different topics. If you want “near Blu-ray quality” you can’t use Plex Transcoding nor Plex Optimize at all because both produce very bad results (compared to what’s possible).
Additionally Plex Optimize has nothing to do with improving quality and especially nothing with “near Blu-ray quality”.
It is already proven that 8 Mbps for 1080p is just plain stupid and pure waste of storage space and bandwidth. But still Plex sticks to it.
It’s a bit Off-topic but shows very well how less Plex knows about bitrates, etc.
I encoded “The day the Earth stood still” with CRF 22 from the Blu-ray I own with AC3 audio and PGS subtitles. As long as I didn’t enabled a subtitle the quality was great (no blocking, etc. in fast-movement scenes). Once I enabled subtitles the picture quality was really bad and had a huge amount of blocking. Transcode was set to “Automatic” and PMS runs on the CPU specified in my signature.
Keep in mind that’s a poor test. You have already transcoded your media. If you turn on subtitles you are forcing Plex to re-transcode your already transcoded media. So what you see is now 2 versions from the original.
A better test is to feed Plex the original and compare the results to your versions.
Yes it still won’t be as good as you are comparing a real-time conversion to an offline version that has been optimized (hopefully).
BTW, your CFR 22 on that Blu ray might be fine but you might need to drop to crf 18 on another to get the same result. It all depends on the movie and how dark/grainy/noisy it appears to start with. Plex has to use a set of presets that give good results across the board while being able to transcode in real-time.
Carlo
@an3k said:
You mix two different topics. If you want “near Blu-ray quality” you can’t use Plex Transcoding nor Plex Optimize at all because both produce very bad results (compared to what’s possible).
Additionally Plex Optimize has nothing to do with improving quality and especially nothing with “near Blu-ray quality”.
It is already proven that 8 Mbps for 1080p is just plain stupid and pure waste of storage space and bandwidth. But still Plex sticks to it.It’s a bit Off-topic but shows very well how less Plex knows about bitrates, etc.
I encoded “The day the Earth stood still” with CRF 22 from the Blu-ray I own with AC3 audio and PGS subtitles. As long as I didn’t enabled a subtitle the quality was great (no blocking, etc. in fast-movement scenes). Once I enabled subtitles the picture quality was really bad and had a huge amount of blocking. Transcode was set to “Automatic” and PMS runs on the CPU specified in my signature.
What are you talking about , Plex were wrong with 8Mbps? When did they choose anything? They let you import your media with any bitrate, and you can then optimize it at any other bitrate!?
And my point about bluray was that you shouldn’t consider netflix’s chosen bitrates (now per title, so can’t generalize) as the Holy grail because they have a set quality output in mind and choose bitrates accordingly. Using more doesnt mean it’s useless, it means for THEIR use case, where they’re serving millions of people at once and pay for bandwidth, the extra bitrate and associated quality isn’t justified.
The desired bitrates for a Plex may very well be different. A pixel pepper might very well notice the image quality drop under 10-12Mbps for certain titles.
@cayars said:
Keep in mind that’s a poor test. You have already transcoded your media. If you turn on subtitles you are forcing Plex to re-transcode your already transcoded media. So what you see is now 2 versions from the original.
That doesn’t matter. You can do a recode of a Blu-ray without losing any quality. And even if you’re limiting bitrate you don’t necessarily see a difference. It depends on the bitrate and other settings you chose.
A better test is to feed Plex the original and compare the results to your versions.
Yes it still won’t be as good as you are comparing a real-time conversion to an offline version that has been optimized (hopefully).
What do you think Optimize means? Improving image quality?
BTW, your CFR 22 on that Blu ray might be fine but you might need to drop to crf 18 on another to get the same result. It all depends on the movie and how dark/grainy/noisy it appears to start with. Plex has to use a set of presets that give good results across the board while being able to transcode in real-time.
That’s not how CRF works. You are thinking in Constant Bit Rate.
@KarlDag said:
@an3k said:
You mix two different topics. If you want “near Blu-ray quality” you can’t use Plex Transcoding nor Plex Optimize at all because both produce very bad results (compared to what’s possible).
Additionally Plex Optimize has nothing to do with improving quality and especially nothing with “near Blu-ray quality”.
It is already proven that 8 Mbps for 1080p is just plain stupid and pure waste of storage space and bandwidth. But still Plex sticks to it.It’s a bit Off-topic but shows very well how less Plex knows about bitrates, etc.
I encoded “The day the Earth stood still” with CRF 22 from the Blu-ray I own with AC3 audio and PGS subtitles. As long as I didn’t enabled a subtitle the quality was great (no blocking, etc. in fast-movement scenes). Once I enabled subtitles the picture quality was really bad and had a huge amount of blocking. Transcode was set to “Automatic” and PMS runs on the CPU specified in my signature.What are you talking about , Plex were wrong with 8Mbps? When did they choose anything? They let you import your media with any bitrate, and you can then optimize it at any other bitrate!?
I don’t understand about what you’re talking. Have you ever checked the Optimize feature or the Client bitrate settings? There is a FIXED 8 Mbps 1080p option and no way to chose eg. 4 Mbps 1080p.
And my point about bluray was that you shouldn’t consider netflix’s chosen bitrates (now per title, so can’t generalize) as the Holy grail because they have a set quality output in mind and choose bitrates accordingly. Using more doesnt mean it’s useless, it means for THEIR use case, where they’re serving millions of people at once and pay for bandwidth, the extra bitrate and associated quality isn’t justified.
Nobody said it’s the holy grail. Additionally it doesn’t matter if you have eg. 1 Tbps in total and have to serve thousands of people or just have 6 Mbps and have to serve two people. What you want to archive is the best quality while using the lowest possible bitrate and Netflix has the most knowledge of how to archive that.
For sure it’s not near Blu-ray quality but that is not what Netflix want to archive nor the Optimize feature is meant for.
The desired bitrates for a Plex may very well be different. A pixel pepper might very well notice the image quality drop under 10-12Mbps for certain titles.
We are NOT talking about internal (LAN) streaming. The main purpose of the Optimize feature is to create lower bitrate versions for people on the WAN. Anybody who is very picky about quality will never use the crappy Optimize feature because a) you can’t configure the encoder well enough b) you get a much more worse quality than encoding manually.
Original (Direct Play) [](/uploads/default/original/3X/c/f/cf08cb879bb5817c6c8b6818892b776a4931b758.jpg “”)
Plex (Trancode) [](/uploads/default/original/3X/0/3/0309d969593d4a6c1421475754553c858d0ce2e4.jpg “”)
As you can see the complete image is full of blocking. The Plex Transcoder does a really bad job here.
@an3k said:
@cayars said:
Keep in mind that’s a poor test. You have already transcoded your media. If you turn on subtitles you are forcing Plex to re-transcode your already transcoded media. So what you see is now 2 versions from the original.That doesn’t matter. You can do a recode of a Blu-ray without losing any quality. And even if you’re limiting bitrate you don’t necessarily see a difference. It depends on the bitrate and other settings you chose.
Not true. You can’t expect to encode media without loosing some quality. This is not lossless transcodes we are doing here. Your 1st generation transcode will look pretty close to the original because FFmpeg has used enough bits/bitrate to achieve your desired results. Any further transcodes from this 1st gen transcode are going to suffer or deteriorate visual/quality wise.
A better test is to feed Plex the original and compare the results to your versions.
Yes it still won’t be as good as you are comparing a real-time conversion to an offline version that has been optimized (hopefully).
What do you think Optimize means? Improving image quality?
I hope you don’t think it’s to improve the image quality because that is NOT WHAT IT DOES. It is OPTIMIZING the format of the media so that when a person views it later it won’t need to be transcoded again. The MO media will be a higher quality than the real-time transcode but neither will be better than the original media it had to start with.
BTW, your CFR 22 on that Blu ray might be fine but you might need to drop to crf 18 on another to get the same result. It all depends on the movie and how dark/grainy/noisy it appears to start with. Plex has to use a set of presets that give good results across the board while being able to transcode in real-time.
That’s not how CRF works. You are thinking in Constant Bit Rate.
You obviously don’t understand this very well. CRF is VARIABLE bitrate not CONSTANT bitrate. Fir constant you specify a bitrate. With variable you set a CONSTANT RATE FACTOR and the algorythms determine as it goes how many bits are needed for each frame/segment to keep the quality at the CRF you specify.
As an example if you took your cell phone positioned it so it was fiexed on an object that also wasn’t moving and recorded an hour of video it would essentially appear to be a still picture. If you re-encded this file using constant rate the file will be big. If you transcode this using variable format with a CRF the file will be tiny.
Now imagine streaming both of these. Would you rather stream a real-time encded file which is going to use a pre-determined bitrate (even when not needed) or would you prefer to stream an “optimized” version?
@an3k said:
@KarlDag said:
@an3k said:
You mix two different topics. If you want “near Blu-ray quality” you can’t use Plex Transcoding nor Plex Optimize at all because both produce very bad results (compared to what’s possible).
Additionally Plex Optimize has nothing to do with improving quality and especially nothing with “near Blu-ray quality”.
It is already proven that 8 Mbps for 1080p is just plain stupid and pure waste of storage space and bandwidth. But still Plex sticks to it.
When MO was first released this was an option. It has now been changed. Now you have fixed choices you must pick from. It’s actually to limiting as 8Mb is way higher than needed for many media types. Maybe someday Plex will figure out we want to control things and know our media best.
Nobody said it’s the holy grail. Additionally it doesn’t matter if you have eg. 1 Tbps in total and have to serve thousands of people or just have 6 Mbps and have to serve two people. What you want to archive is the best quality while using the lowest possible bitrate and Netflix has the most knowledge of how to archive that.
Why o’ why do you think this? Personally I think many of us here do a much better job than Netflix ever will. Our needs our different. It’s actually QUITE EASY for us. You play with FFMpeg and find out what CRF works for you across the board or for different media types (eg animations, drama, action) and you transcode these using your CRF. They will then transcode using only the minimal bitrate needed to match your visual/quality selection.
For sure it’s not near Blu-ray quality but that is not what Netflix want to archive nor the Optimize feature is meant for.
Exactly, much of Netflix’s conversions are far from BR quality. A Lot of their quote 4K unquote material isn’t as good as a BR rip I will make using only 1080p.
So why should we follow a sub-par way of transcoding our media?
In your message with the two videos you are comparing a variable bitrate to a constant bitrate video and the 2nd video was derived from the 1st. You are comparing apples and oranges.
And this is EXACTLYMedia Optimization can work so well for many people. It’s not meant to work the way you just demonstrated.
To use it the preferred way take the RAW BR rip and play it back letting the Plex transcoder do it’s thing in real-time. Then use Media Optimizer to create the same version and play this back. You will see a world of difference and that is why it’s called Media OPTIMIZER.
Carlo
I actually was going to answer your postings but you misunderstood nearly most of what I wrote and also wrote so much nonsense that I don’t give a ■■■■ anymore.
I said:
BTW, your CFR 22 on that Blu ray might be fine but you might need to drop to crf 18 on another to get the same result. It all depends on the movie and how dark/grainy/noisy it appears to start with. Plex has to use a set of presets that give good results across the board while being able to transcode in real-time.
You said:
That’s not how CRF works. You are thinking in Constant Bit Rate.
I’m saying:
I’m saying that you have variable and constant mixed up. You use the CRF (constant rate factor) to determine a quality to achieve and the program will use whatever amount of bits it takes to reproduce the media at the quality level specified. For example action sequences might require a lower (better) CRF to not get blocky or show action sequence artifacts as it will require more bits. While a drama or animation can get by with a higher CRF (worse quality) as the scenes are much easier to transcode. Fast action or very detailed scenes require a lower CRF to reproduce closer to the original. You could (I do) encode everything at CRF 18 to get a high level of detail in everything you re-encode.
You said:
Nobody said it’s the holy grail. Additionally it doesn’t matter if you have eg. 1 Tbps in total and have to serve thousands of people or just have 6 Mbps and have to serve two people. What you want to archive is the best quality while using the lowest possible bitrate and Netflix has the most knowledge of how to archive that.
I said:
Why o’ why do you think this? Personally I think many of us here do a much better job than Netflix ever will. Our needs our different. It’s actually QUITE EASY for us. You play with FFMpeg and find out what CRF works for you across the board or for different media types (eg animations, drama, action) and you transcode these using your CRF. They will then transcode using only the minimal bitrate needed to match your visual/quality selection.
I’m saying:
I’m saying: I agree with what you said right up to the point of you saying Netflix has the most knowledge of how to archive that. They in fact might have the knowledge but THEY DO NOT DO THIS. The bitrates they use are less than what most of us would use. They have to cut corners here and there to stream to so many people at the same time. They typically avoid blocky or artifacts but they do this by softening the picture and loose a lot of detail at times. Most of us don’t want to do this and we want to reproduce the Blu-Ray as close as possible. So I’m saying we don’t want to follow Netflix’s lead on this as it’s not always in our best interest. For some people maybe.
@cayars said:
The problem:
Here is the major problem. Typically when we convert our files externally using my scripts, handbrake,
xMedia recoder, etc we convert/transcode these files using VBR and a target CRF. Variable Bit Rate in a nutshell only uses enough bits to convert the media while meeting the CFR we set. So you can’t calculate what the bitrate will be or the file size (unless doing a two pass encoding). \
Don Melton created a “Constrained” VBR method basically giving the best of both worlds. A CRF level with contained bit rate.
I typically use this string with a CRF of 16 and encodes come out to be around 8,000 kpbs generally:
vbv-maxrate=8000:vbv-bufsize=4000:crf-max=25
In my case, I have a bunch of 1080p 60FPS videos that Chromecast can not handle. It can only handle 720 60FPS. I wanted to optimize those but I can not get it to do 60FPS. Plex via Google+ said “You could copy an existing profile used for Media Optimizer, modify it to remove that limitation, and save it in a /Profiles subfolder of your main PMS data directory if you wanted.” but a setting is much better.
Anyone know how to modify it manually at least?
Thanks!
@Kyle Verry said:
In my case, I have a bunch of 1080p 60FPS videos that Chromecast can not handle. It can only handle 720 60FPS. I wanted to optimize those but I can not get it to do 60FPS. Plex via Google+ said “You could copy an existing profile used for Media Optimizer, modify it to remove that limitation, and save it in a/Profilessubfolder of your main PMS data directory if you wanted.” but a setting is much better.Anyone know how to modify it manually at least?
Thanks!
I myself would not follow his guide. Some of the things he is doing will cause problems with some programs. The variable bitrate with an upper limit part is OK if that is what you are after BUT I would not use this for your normal encodes as you are forcing you library to be constrained and you will get some type of artifacts/blocky type things. This is unavoidable when you don’t give enough bits to the process to represent your video to the CBR you are asking it to achieve. It would be fine for real-time transcoding however as this is constrained usually anyway.
Early 2021 clean-up: implemented
