DTS works fine in a MKV, but I do not think it is supported in MP4, on the Roku platform. I will test it out this weekend. If something has changed, it was the only advantage that MKV had over MP4 when I started encoding my library.
Edit: This is old, but this thread (and comment by @destructo ) is the source of my concern:
Edit 2: Roku now indicates that DTS in MP4 may be playable:
Hopefully the profile for Roku supports this as well.
Today’s Server Update includes the option to modify the h264 preset, but not the CRF value. What does that mean exactly as far as results go? (I’m not super well versed in FFMPEG commands and options). I assume we’ll get smaller files, but not necessarily better quality?
I don’t know what settings are changeable but not just CRF is responsible for quality. To be honest I haven’t updated since 0.9.14.4 because the development is going in the wrong direction.
@an3k said:
I don’t know what settings are changeable but not just CRF is responsible for quality. To be honest I haven’t updated since 0.9.14.4 because the development is going in the wrong direction.
Thought about it some more, since we’re going for constant bitrate and not constant quality, crf probably doesn’t really apply here.
That said, I disagree. This (coupled with the leak showing they’re working on bandwidth limits) shows Plex listen to us somewhat, though slowly.
Sure, some other options so there offer better/more complete servers side settings, but without sufficient clients they’re not as useful. In my case, not having a playstation client is a no go for most of my users, for example.
Wow, I can’t believe we got half of what we really needed. This setting without the CRF still makes this pretty useless.
@an3k said:
I don’t know what settings are changeable but not just CRF is responsible for quality. To be honest I haven’t updated since 0.9.14.4 because the development is going in the wrong direction.
Actually it IS the biggest contributor to quality generally speaking. I think most people are going to want to set the CRF to something between 18 and 20 to make long term MO files worth keeping. Things like the preset mainly affect the amount of compression achieved which is OK and needed but by itself still doesn’t give us what is needed for the MO feature. You NEED to set both to control the quality and the compression/storage space needed for the files.
@cayars said:
@an3k said:
I don’t know what settings are changeable but not just CRF is responsible for quality. To be honest I haven’t updated since 0.9.14.4 because the development is going in the wrong direction.Actually it IS the biggest contributor to quality generally speaking. I think most people are going to want to set the CRF to something between 18 and 20 to make long term MO files worth keeping. Things like the preset mainly affect the amount of compression achieved which is OK and needed but by itself still doesn’t give us what is needed for the MO feature. You NEED to set both to control the quality and the compression/storage space needed for the files.
Even in this case, where quality is determined by average bitrate and not constant quality?
@KarlDag said:
Actually it IS the biggest contributor to quality generally speaking. I think most people are going to want to set the CRF to something between 18 and 20 to make long term MO files worth keeping. Things like the preset mainly affect the amount of compression achieved which is OK and needed but by itself still doesn’t give us what is needed for the MO feature. You NEED to set both to control the quality and the compression/storage space needed for the files.
Even in this case, where quality is determined by average bitrate and not constant quality?
Godd question. And IMO not. Since the transcoder doesn’t work in CRF mode but in max bandwidth mode.
Here, the two determining factors are:
a) the maximum allowed bandwidth (primary factor)
b) the speed profile (a lower ‘speed’ allows the transcoder to try and compare compression strategies to squeeze more ‘quality’ into the allotted bandwidth)
Putting the encoder into CRF mode makes it disregard any bandwidth restrictions completely, which is bad for streaming. And streaming is what we are optimizing for.
edit, more backgroud:
CRF mode is good for archiving. You define a maximum allowed deviation in quality from the source file (this is the CRF value). You get a file of size x. Simply dividing this filesize x by the play duration only gets you the average bitrate. Which is not very useful if you have a streaming scenario where the maximum bitrate is limited. A ‘CRF encoding’ can still contain passages where the allowed bitrate is exceeded.
Here is an experiment:
if you have a Windows box download this tool: winhoros.de
It generates a graph of the bitrate of a video file. (It is a bit tricky to feed it mkv files, but it is possible. Just put in the ‘file name’ box *.* and Enter. After that you can select every file type.)
Use this to compare a ‘CRF file’ of average 8mbps with an 8mbps file which was created in ‘average bitrate’ mode.
(with all other parameters being equal of course.)
Here is a graph of a CRF encoding of Avatar. As you can see, it is only possible to stream this file in direct play mode with a good client and a wired connection:
Don’t get these confused. In a nutshell the “Level” controls the amount of compression while the CRF controls the “quality”.
Let me see if I can give you a better understanding. The CRF range is from 0 (best) to 51 (worst). From 16 to 30 is basically the usable range and anything on either side of this is a “waste”. The range is exponential and the typically values are from 18 to 26 with 22 being the x.264 default. 18 is nearly visually lossless. Iuse 18 for blu ray rips and you can’t tell the difference from the original 99%+ of the time.
Preset Level is the amount of compression vs time of encoding. The more time/resources you give the algorithm to use the better it can compress WHILE achieving the quantizer values (CRF).
So lets say you set the CRF to 20 and use the VERYFAST preset. You will end up with a “bigger” file. The same 20 CRF with a preset of VERSLOW will end up with a “smaller” file. The files will be bigger/smaller depending on how much time the algorithm is given to computer the bitrate needed for that frame (and looking at past/future frames).
From the ffmpeg FAQ: It’s diminishing returns: veryslow helps about 3% compared to the slower preset, slower helps about 5% compared to the slow preset, and slow helps about 5-10% compared to the medium preset. (there is in the fast, faster, veryfast, superfast, ultrafast). Superfast is typically what the Plex real-time transcoder uses.
So you can see there is going to be a big difference between the usually extremes of VERYFAST and VERYSLOW. Veryfast will be a bigger file that uses more bitrate and veryslow will be a smaller file using less bits. Both files will essentially have the same quality when viewed (CRF).
SO IDEALLY for Media Optimizer to be powerful and truly useful you would probably want to be able to set the CRF between 18 to 20 (I’d suggest 18) and use a preset of VERYSLOW to get the most compression and to save disk space. Remember compression equals less bits to transfer while keeping the same visual quality.
Does that make it clearer?
Carlo
@KarlDag said:
@an3k said:
I don’t know what settings are changeable but not just CRF is responsible for quality. To be honest I haven’t updated since 0.9.14.4 because the development is going in the wrong direction.Thought about it some more, since we’re going for constant bitrate and not constant quality, crf probably doesn’t really apply here.
We could go with CRF but - sorry to have to say it again - Plex is doing it completely wrong. Even with CRF you can limit the maximum bandwidth / quality. That means that you could do CRF20 (thus VBR) but limit bitrate to, lets say 4 Mbps. For sure that is not a real CRF20 anymore but every scene that needs less than or equal to 4 Mbps would get CRF20 and every scene requiring more would get a higher CRF / be limited to 4 Mbps.
That said, I disagree. This (coupled with the leak showing they’re working on bandwidth limits) shows Plex listen to us somewhat, though slowly.
Sure, some other options so there offer better/more complete servers side settings, but without sufficient clients they’re not as useful. In my case, not having a playstation client is a no go for most of my users, for example.
I used the PS4 client most in the beginning until I got a FireTV 4K. It has the same design but works much better. Seeking is faster, responsiveness is much better and it isn’t that restricted regarding AC3, Profiles and Levels. Beside DTS it Direct Plays everything else while the PS4 client was always in Transcode.
@cayars said:
@an3k said:
I don’t know what settings are changeable but not just CRF is responsible for quality. To be honest I haven’t updated since 0.9.14.4 because the development is going in the wrong direction.Actually it IS the biggest contributor to quality generally speaking. I think most people are going to want to set the CRF to something between 18 and 20 to make long term MO files worth keeping. Things like the preset mainly affect the amount of compression achieved which is OK and needed but by itself still doesn’t give us what is needed for the MO feature. You NEED to set both to control the quality and the compression/storage space needed for the files.
As I said, CRF is one setting you need to control quality. It is correct that the preset controls how well the resulting stream is compressed but settings like --me, --trellis or --deblock define how well the quality is preserved.
The problem here is that all the possible settings are too complex for most users. I guess this is the main reason why they’re not implemented (in the Plex GUI) but all we want is the ability to fully modify the used presets so that those users who know what they’re doing can optimize (and hopefully share) their presets. That way Plex could provide standard presets and the nerds could optimize these and provide improved versions. Then users who don’t have a clue about all these settings could either stick with the Plex standard or download and “install” the community optimized ones. Nobody it talking about overwriting/replacing the Plex standard presets.
And again we are at the old topic “Plex is going the wrong way”. If there were a presets directory, separated by subdirectories for SD, HD, FullHD and 4K with some Plex standard preset-files for the various bandwidth settings we easily could copy one of the presets, modify it and save it as a new preset. Additionally it would be easy for clients to read these presets from the server and offer these as Quality settings in the clients GUI. Nevermind, Plex isn’t even listening and I’m sick of wasting my time and writing how they could improve it while they don’t really care.
@cayars said:
Level is the amount of compression vs time of encoding. The more time/resources you give the algorithm to use the better it can compress WHILE achieving the quantizer values (CRF).
This is absolutely wrong. The Level just defines the maximum bitrates, bandwidth, buffer sizes, etc. and works in conjunction with the Profile used. It has absolutely nothing to do with compression! See Advanced Video Coding - Wikipedia
@OttoKerner said:
Putting the encoder into CRF mode makes it disregard any bandwidth restrictions completely, which is bad for streaming. And streaming is what we are optimizing for.
I disagree with this. What the CRF does is set the quantizer to expect it to achieve a certain similarity to the original. It may or may not require use more bits depending on the source and the expected result.
edit, more backgroud:
CRF mode is good for archiving. You define a maximum allowed deviation in quality from the source file (this is the CRF value). You get a file of a certain size.
No you don’t. You can’t determine the size based on the CRF. You’re referring to limiting and that is not what the CRF does.
Simply dividing this filesize by the play duration only gets you the average bitrate. Which is not very useful if you have a streaming scenario where the maximum bitrate is limited. A ‘CRF encoding’ can still contain passages where the allowed bitrate is exceeded.
That is true. But this is always true when re-compressing files. With ffmpeg you can set a CRF value but then limit the upper bounds it can use in any one portion or over a portion of a file (x frames from each other). By doing this you can make sure you have the highest quality given per a specific bandwidth limit.
Here is an experiment:
if you have a Windows box download this tool: winhoros.de
It generates a graph of the bitrate of a video file. (It is a bit tricky to feed it mkv files, but it is possible. Just put in the ‘file name’ box . and Enter. After that you can select every file type.)
I’m not sure what you’re trying to show with this graph. You’re comparing apples to oranges. I think this is the same “confusion” Plex is putting on Media Optimizer. I believe Plex thinks they need to control the bitrate.
Many people will be quite happy with MO regardless of size of file. They just want to be able to transcode things like VC-1 blu ray rips in the background to get them in a format that can be streamed to devices without the buffering that takes place without a high-end CPU.
Remember we can already select the limit for the bandwidth (release 1), we can now select the compress or preset (release 2) but we still can’t choose our target quality (CRF) which is needed.
Once we have those 3 things this feature (MO) can be tailored specifically to what the user needs. As an example you could keep “original” to not artifically set a bandwidth with a CRF of 18 and a preset of veryslow to get a streamable version of a blu ray that will play without buffering.
You could setup a 4Mb 720 preset veryslow with a crf of 22 for those without a lot of bandwidth wanting to stream to friends.
You could setup a 2MB 720 slow CRF 24 for use to stream to smart phones.
So as you can see by being able to control each of these things we could setup MO to do exactly the task at hand!
Carlo
@an3k said:
@cayars said:
Level is the amount of compression vs time of encoding. The more time/resources you give the algorithm to use the better it can compress WHILE achieving the quantizer values (CRF).This is absolutely wrong. The Level just defines the maximum bitrates, bandwidth, buffer sizes, etc. and works in conjunction with the Profile used. It has absolutely nothing to do with compression! See Advanced Video Coding - Wikipedia
@an3k I wasn’t talking about the “profile level”. I was talking about the “preset level”. Thought that was obvious from the context. I should not have used the word “level” in hind site. 
The top section of this FAQ pretty much covers it:
https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ
@cayars said:
@an3k said:
@cayars said:
Level is the amount of compression vs time of encoding. The more time/resources you give the algorithm to use the better it can compress WHILE achieving the quantizer values (CRF).This is absolutely wrong. The Level just defines the maximum bitrates, bandwidth, buffer sizes, etc. and works in conjunction with the Profile used. It has absolutely nothing to do with compression! See Advanced Video Coding - Wikipedia
@an3k I wasn’t talking about the “profile level”. I was talking about the “preset level”. Thought that was obvious from the context. I should not have used the word “level” in hind site.
After I saw your last reply to @OttoKerner I thought you’re talking about something else but then it was already too late
I’m going to install the latest PMS onto my NAS so I can play with it and keep up with you all. As I said I’m still at 0.9.14.4 because I actually don’t need all the current “features” that came after that version.
@cayars said:
CRF mode is good for archiving. You define a maximum allowed deviation in quality from the source file (this is the CRF value). You get a file of a certain size.
No you don’t. You can’t determine the size based on the CRF. You’re referring to limiting and that is not what the CRF does.
Sorry if I expressed myself incorrectly here. I was just referring to the fact that you usually cannot determine the resulting file size when using CRF.
With ffmpeg you can set a CRF value but then limit the upper bounds it can use in any one portion or over a portion of a file (x frames from each other). By doing this you can make sure you have the highest quality given per a specific bandwidth limit.
This is a new information for me. And I fully agree that this the most desirable MO for our scenario.
Many people will be quite happy with MO regardless of size of file. They just want to be able to transcode things like VC-1 blu ray rips in the background to get them in a format that can be streamed to devices without the buffering that takes place without a high-end CPU.
I am not sure about this. I think many wish to use the MO to create files to serve for remote connections which are indeed tightly controlled in their bitrate. Simply because many ppl don’t have much upstream bandwidth available.
Together with the coming upper limit preference for remote streaming this would be very handy.
Just got this explanation from an x264 developer
there’s very little completely static bit rate encodes because generally that’s not something you want. just specifying the bit rate (tries to) make sure the bit rate over the whole encode is what you wanted (Average Bit Rate). if you have bandwidth limitations you then add VBV/HRD control to that (and that doesn’t change at all as a fact whether you’re using ABR or CRF)
I don’t have good examples (different sources) but here are two
Encoded with Bitrate set to 4968 
Encoded with CRF set to 22 
Edit: Yes’ I’ll re-encode the first one again but with CRF set 
@cayars said:
So you can see there is going to be a big difference between the usually extremes of VERYFAST and VERYSLOW. Veryfast will be a bigger file that uses more bitrate and veryslow will be a smaller file using less bits. Both files will essentially have the same quality when viewed (CRF).SO IDEALLY for Media Optimizer to be powerful and truly useful you would probably want to be able to set the CRF between 18 to 20 (I’d suggest 18) and use a preset of VERYSLOW to get the most compression and to save disk space. Remember compression equals less bits to transfer while keeping the same visual quality.
Does that make it clearer?
Carlo
Given that were working with a max bitrate, wouldn’t the slow preset be able to fit in more visual quality per xMbps than the fast preset? It will only give a smaller file size?
@an3k said:
I used the PS4 client most in the beginning until I got a FireTV 4K. It has the same design but works much better. Seeking is faster, responsiveness is much better and it isn’t that restricted regarding AC3, Profiles and Levels. Beside DTS it Direct Plays everything else while the PS4 client was always in Transcode.
For sure, I mostly use a Nvidia Shield TV and a chromecast (and android devices) myself, but my shared users have playstations, and I’m not buying them clients 
@KarlDag said:
@cayars said:
So you can see there is going to be a big difference between the usually extremes of VERYFAST and VERYSLOW. Veryfast will be a bigger file that uses more bitrate and veryslow will be a smaller file using less bits. Both files will essentially have the same quality when viewed (CRF).Given that were working with a max bitrate, wouldn’t the slow preset be able to fit in more visual quality per xMbps than the fast preset? It will only give a smaller file size?
Here is a better example.
–preset medium 
–preset slower 
@an3k said:
@KarlDag said:
@cayars said:
So you can see there is going to be a big difference between the usually extremes of VERYFAST and VERYSLOW. Veryfast will be a bigger file that uses more bitrate and veryslow will be a smaller file using less bits. Both files will essentially have the same quality when viewed (CRF).Given that were working with a max bitrate, wouldn’t the slow preset be able to fit in more visual quality per xMbps than the fast preset? It will only give a smaller file size?
Here is a better example.
–preset medium
–preset slower
What are you trying to show me, please? I see bitrate, doesn’t mean image quality has changed… What am I missing?
