X264 Video Quality
Candi Ruman
This guide focuses on the encoder x264. It assumes you have ffmpeg compiled with --enable-libx264. If you need help compiling and installing see one of our compiling guides. See HWAccelIntro for information on supported hardware H.264 encoders.
This method allows the encoder to attempt to achieve a certain output quality for the whole file when output file size is of less importance. This provides maximum compression efficiency with a single pass. By adjusting the so-called quantizer for each frame, it gets the bitrate it needs to keep the requested quality level. The downside is that you can't tell it to get a specific filesize or not go over a specific size or bitrate, which means that this method is not recommended for encoding videos for streaming.
A preset is a collection of options that will provide a certain encoding speed to compression ratio. A slower preset will provide better compression (compression is quality per filesize). This means that, for example, if you target a certain file size or constant bit rate, you will achieve better quality with a slower preset. Similarly, for constant quality encoding, you will simply save bitrate by choosing a slower preset.
For example, if your input is animation then use the animation tuning, or if you want to preserve grain in a film then use the grain tuning. If you are unsure of what to use or your input does not match any of tunings then omit the -tune option. You can see a list of current tunings with -tune help, and what settings they apply with x264 --fullhelp.
The -profile:v option limits the output to a specific H.264 profile. You usually do not need to use this option and the recommendation is to omit setting the profile which will allow x264 to automatically select the appropriate profile.
Some devices (mostly very old or obsolete) only support the more limited Constrained Baseline or Main profiles. You can set these profiles with -profile:v baseline or -profile:v main. Most modern devices support the more advanced High profile.
Use this rate control mode if you are targeting a specific output file size, and if output quality from frame to frame is of less importance. This is best explained with an example. Your video is 10 minutes (600 seconds) long and an output of 200 MiB is desired. Since bitrate = file size / duration:
Note that lossless output files will likely be huge, and most non-FFmpeg based players will not be able to decode lossless. Therefore, if compatibility or file size are an issue, you should not use lossless.
Tip: If you're looking for an output that is roughly "visually lossless" but not technically lossless, use a -crf value of around 17 or 18 (you'll have to experiment to see which value is acceptable for you). It will likely be indistinguishable from the source and not result in a huge, possibly incompatible file like true lossless mode.
While -preset chooses the best possible settings for you, you can overwrite these with the x264-params option, or by using the libx264 private options (see ffmpeg -h encoder=libx264). This is not recommended unless you know what you are doing. The presets were created by the x264 developers and tweaking values to get a better output is usually a waste of time.
In the above example, -bufsize is the "rate control buffer", so it will enforce your requested "average" (1 MBit/s in this case) across each 2 MBit worth of video. Here it is assumed that the receiver / player will buffer that much data, meaning that a fluctuation within that range is acceptable.
Use this mode if you want to constrain the maximum bitrate used, or keep the stream's bitrate within certain bounds. This is particularly useful for online streaming, where the client expects a certain average bitrate, but you still want the encoder to adjust the bitrate per-frame.
This will effectively "target" -crf 23, but if the output were to exceed 1 MBit/s, the encoder would increase the CRF to prevent bitrate spikes. However, be aware that libx264 does not strictly control the maximum bit rate as you specified (the maximum bit rate may be well over 1M for the above file). To reach a perfect maximum bit rate, use two-pass.
Going from medium to slow, the time needed increases by about 40%. Going to slower instead would result in about 100% more time needed (i.e. it will take twice as long). Compared to medium, veryslow requires 280% of the original encoding time, with only minimal improvements over slower in terms of quality.
You may need to use -vf format=yuv420p (or the alias -pix_fmt yuv420p) for your output to work in QuickTime and most other players. These players only support the YUV planar color space with 4:2:0 chroma subsampling for H.264 video. Otherwise, depending on your source, ffmpeg may output to a pixel format that may be incompatible with these players.
I don't understand what the cabac option does exactly. But let's say for example that it adds some extra lossless compression, resulting in a smaller video file, but the decoding machine would need to do extra work to decompress the file
In that case, the --no-cabac option would skip that extra compression, resulting in no loss of quality, with a bigger file size, and the decoding machine would not need to decompress the extra compression, saving CPU work on the decoding side
Basically, encode the video (using best guess values), check it for SSIM against the original. Decide what percentage of similarity is acceptable. (Above 98% is supposed to be an imperceivable difference) Check your file size and repeat with new options as necessary. You can get away with using samples, so you don't have to do the whole thing, but then the final SSIM is only a guess.
ffmpeg -i file.mp4 -c:v libx265 -c:a copy -vtag hvc1 file.mkv
With this I got a file size about 50% of the original.
However, it seem the result was not of the same quality. It had a much lower bitrate.
Although I could not see any clear difference when playing.
From what I could find mentioned was that -crf 18 means of equal quality, and that 14-18 mean lossless.
However I got a file size with x265 that was over twice the size of the x264 file.
Should it not be possible to convert to x265 and get same quality as x264, but with smaller file size?
The range of the quantizer scale is 0-51: where 0 is lossless, 23 is default, and 51 is worst possible. A lower value is a higher quality and a subjectively sane range is 18-28. Consider 18 to be visually lossless or nearly so: it should look the same or nearly the same as the input but it isn't technically lossless.
The debate of x264 vs. x265 has been a tough one for developers and editors alike. While both have their merits, understanding them well can be the difference between a great user experience and a buffering nightmare.
So, in the grand debate of x264 vs. x265, remember: while each has its strengths and trade-offs, platforms like Cloudinary offer an overarching solution that takes the guesswork out of video optimization.
Does anyone know whether or not a straight conversion of x264 (AVC) to x265 (HEVC) reduces quality at all, or it will just have better efficiency in compression?
I don't mean re-encoding, or does that actual process have to involve re-encoding?
Also, what would be best for this, as it's my understanding software such as handbrake only re-encodes.
To convert from one codec to another always involves re-encoding. Whether it reduces quality or not, depends on the settings used during the process. The main benefit to re-encode to x265 is to save space, but generally you're not going to save heaps of space, unless you also lose some quality. I think you could estimate that x265 is 50% of the size of x264 for similar quality.
There's also a downside to converting to x265 - you need more powerful hardware for playback, and there are fewer devices out there that can even play it at all. And if you're streaming from an Emby server to something like an iOS device, Emby server will need to use more CPU power whilst transcoding an x265 file compared to an x264 file.
4) For Remote users, all that h265 content is just transcoded to h264 again, so now you have extra transcoding, just to get back to h264 you started with to begin with. I am assuming that just as with playback, transcoding h265 will consume more resources than transcoding h264.
Well, I have done a fair bit of playing around and looking into it myself, even done some encodes from full blue-ray which do take time a bit of extra time. I do however rather want to future proof and put up with my media being transcoded back to x264 for the devices I currently have as in the near future, most devices will be able to natively play this format as it is my understanding all recent UHD TV's seem to be able to natively play now?
Also, in regards to Rpi's, I will be building a new PC/server/HTPC next year some time to be able handle the load of encoding and trans-coding to older devices where needed.
Back to my orginal question though, you guys have given some very useful information but I need to clarify - would their be any substantial loss from RE-ENCODING to x265 that would be considered a huge drawback in terms of quality in comparison to say encoding to x265 straight from the source? I am just seeing if it's worth while to re-encode what I have of x264 to x265 and what would be the best solution for this as I wouldn't know how to go about this in handbrake. Is their something that can re-encode with keeping the compression to a minimum apart from the compression that takes place from x264 to x265 to reduce the file size. (hopefully that makes sense).
c80f0f1006