So lets take a step back and look at the lowest 1% of the frames. Because if every frame was that good, we shouldn’t need more than 6Mbps x265 or 10Mbps x264 4K video. However the averages don’t tell the whole story.
USING MAKEMKV COMMAND LINE MP4
Sample commands I used to generate these files: ffmpeg -i movie.mkv -c:v libx265 -b:v 500k -x265-params pass=1 -an -f mp4 NULįfmpeg -i movie.mkv -c:v libx265 -b:v 500k -x265-params pass=2 -an h265\movie_500.mp4įfmpeg -i my_movie.mkv -i h265\movie_500.mp4 -lavfi ssim=265_movie_500_ssim.log -f null - Lowest 1% SSIM The horizontal line shows this where x264 needs 14Mbps to match x265’s 9Mbps, a 5000kbps difference! If we wanted to go by YouTube’s recommendations for a video file that will be re-encoded again, you would only need a 25Mbps x265 file instead of a 35Mbps x264 video.
On the section of video I chose, x264 needed considerably more bitrate to achieve the same score.
The SSIM result is done frame by frame, so we have to average them all together to see which is best overall. It means there is less differences between the original and the compressed one Generated via Python and matplotlib Put simply, the closer the result is to 1 the better. Afterwards compared them to the original using the Structural Similarity Index (SSIM).
Then I ran multiple two pass ABR runs using ffmpeg for both x264 and x265 using the same target bitrate. ffmpeg -y -ss 07:48 -t 60 -i my_movie.mkv-vf zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p -c:v libx265 -preset ultrafast -x265-params lossless=1 -an -sn -dn -reset_timestamps 1 movie_non_hdr.mkv Average Overall SSIM
USING MAKEMKV COMMAND LINE CODE
I found this code to convert the 10-bit “HDR” yuv420p10le colorspace down to the standard yuv420p 8-bit colorspace from the colourspace blog so props to them for having a handy guide just for this. Thus comparing the two encoders via their default 8-bit compressors. First thing I did was to chop out a minute segment and promptly remove the HDR. To find out I would need a lot of comparable data. So I had to ask myself: How much better is x265 than x264? But when I looked at the videos I was enjoying just fine at CRF 22, they were mostly coming out with less than a 10Mbps bitrate. Now I know that x265 can be around 50% more efficient than x264, and that YouTube needs it higher quality coming in so when they re-compress it it will still look good. They claim that a 4K video coming into their site should optimally be 35~45Mbps when encoded with the older x264 codecs. Then I recently read YouTubes suggest guidelines for bitrates. That way I know I should never be disappointed. Therefore I played it safe, bump it down a notch and just encode all of my stuff with x265 10-bit at CRF of 20 on Slow preset. Through some experimentation I found that I personally never can really see a difference between anything lower than 22 using a Slow present. It states that for 4K videos with x265 they suggest a Constant Rate Factor (CRF) encoding in the range of 22-28 (the larger the number the lower the quality). In the past, I went straight to Handbrake’s documentation. I mainly use Handbrake now use ffmpeg because I learned Handbrake only has a 8-bit internal pipeline. I want a setting that I can use on any incoming 4K HDR video I buy. The honest to god true answer is “it depends”, however I find that answer unsuitable for my own needs. What are the best settings for me to use when encoding x265 videos? What are the best settings for me to use when encoding x265 videos?.
0 kommentar(er)
