<p>The CRF scales for x264 and x265 do not correspond. x265 CRF 28 is supposed to be e<a href="https://trac.ffmpeg.org/wiki/Encode/H.265" rel="noreferrer">quivalent</a> to x264 CRF 23. But x265 is not yet as mature in its development as x264, so take that CRF equivalence with a pinch of salt. </p>

<p>That said, you can try to establish your own calibration between the current versions of the encoding libraries in your ffmpeg by running the following command, which executes two popular video quality metrics:</p>

<pre><code>ffmpeg -i encoded-video.mp4 -i reference-video.mp4 -lavfi "ssim;[0:v][1:v]psnr" -f null -
</code></pre>

<p>The final lines of the console output will contain:</p>

<pre><code>[Parsed_ssim_0 @ 000000000039ad80] SSIM Y:0.984483 U:0.980458 V:0.980921 All:0.983219 (17.751712)
[Parsed_psnr_1 @ 0000000000398320] PSNR y:42.63 u:43.19 v:44.09 average:42.90 min:42.07 max:46.16
</code></pre>

<p>So, run the command once with the x264 output and once with x265 and compare with different x265 outputs, till you get similar measures. Of course, <a href="https://en.wikipedia.org/wiki/Video_quality#Examples" rel="noreferrer">these metrics</a> aren't perfect but you can use them as a rough guide to establish equivalence.</p>

CC BY-SA 3.0
2015-10-21T19:15:38.217Z
Hmm interesting, may i ask why this scales doesn't correspond? Is a wanted design with a bigger amount of CRF values or could be considered this way because libx265 is still not mature enough in ffmpeg?
user3450548
CC BY-SA 3.0
2015-10-21T19:31:03.800Z
An addition to the previous comment. In ffmpeg documentation that you linked is said that x265 crf 28 is roughly equivalent to x264 crf 23. So, if generally the CRF of h265 are "better" qualitatively speaking than the x264 ones how is possible that the encode results of x265 is worst than x264 with same CRF ? Still a vlc bad decoding + libx265 too young?
user3450548
CC BY-SA 3.0
2015-10-21T19:35:15.197Z
28 and 23 are the default CRF values of x265 and x264 respectively, hence the supposed equivalence. The short answer to the deviation from expected performance is that x265 is still under "heavy development". Nothing to do specifically with libx265 included with ffmpeg  See http://forum.doom9.org/showthread.php?t=170986 and http://compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf
Gyan
CC BY-SA 3.0
2015-10-21T20:05:15.750Z
I see, so because of this heavy development status even if I decide to move from ffmpeg and libx265 to another encoder the results will not change so much right? There aren't some commercial products based on x265 nowadays? Should have been already almost completed in all its parts!
user3450548
CC BY-SA 3.0
2015-10-22T07:51:19.380Z
If you look at the PDF I linked in the last comment, there are many encoders out there - most proprietary. My observation is confined to standalone x265 or its deployment, whether in ffmpeg or anything else. Those other encoders might be better - I haven't studied that PDF closely.
Gyan
CC BY-SA 4.0
2021-07-04T18:31:01.233Z
What's the x265 equivalent of x264 crf 18?
Michael
CC BY-SA 4.0
2021-07-05T03:58:30.907Z
Around 21.......
Gyan
CC BY-SA 3.0
2015-10-21T05:27:12.827Z
2015-10-21T05:44:43.920Z
2015-10-21T05:44:43.920Z
Gyan
<p>I'm doing some experiments with HEVC x265.</p>

<p>I have a raw footage and the quality of details of h264 with same CRF setting looks better than h265.</p>

<p>Shouldn't be the opposite?</p>

<p>Maybe my setup isn't the best: I'm using ffmpeg for transcoding and vlc for review the videos, then i copy the screen content and compare the screens on a program like photoshop.</p>

<p>FFmpeg commands I using are the following:</p>

<pre><code>ffmpeg -i input.mp4 -c:v libx264 -crf 30 -c:a copy output_h264.mkv
</code></pre>

<p>and</p>

<pre><code>ffmpeg -i input.mp4 -c:v libx265 -crf 30 -c:a copy output_h265.mkv
</code></pre>

<p>I used 30 as CRF for testing purposes because the artifacts are more visible :)</p>

<p>Could the loss of quality be caused by VLC and its experimental support in deconding h265? Maybe something more visible at lower bitrates?</p>

<ffmpeg><video-quality><transcoding><h.264><h.265>
What CRF or settings I should choose for h265 in order to achieve a similiar quality of h264?
user3450548
# What CRF or settings I should choose for h265 in order to achieve a similiar quality of h264?

(Asked by: username_0 on 2015-10-20)

I'm doing some experiments with HEVC x265.
I have a raw footage and the quality of details of h264 with same CRF setting looks better than h265.
Shouldn't be the opposite?
Maybe my setup isn't the best: I'm using ffmpeg for transcoding and vlc for review the videos, then i copy the screen content and compare the screens on a program like photoshop.
FFmpeg commands I using are the following:
ffmpeg -i input.mp4 -c:v libx264 -crf 30 -c:a copy output_h264.mkv

and
ffmpeg -i input.mp4 -c:v libx265 -crf 30 -c:a copy output_h265.mkv

I used 30 as CRF for testing purposes because the artifacts are more visible :)
Could the loss of quality be caused by VLC and its experimental support in deconding h265? Maybe something more visible at lower bitrates?

**Tags:** ffmpeg, video-quality, transcoding, h.264, h.265


---

## 1 answers

### Answer by username_1 on 2015-10-21. Score: 8 | Accepted answer

The CRF scales for x264 and x265 do not correspond. x265 CRF 28 is supposed to be equivalent to x264 CRF 23. But x265 is not yet as mature in its development as x264, so take that CRF equivalence with a pinch of salt. 
That said, you can try to establish your own calibration between the current versions of the encoding libraries in your ffmpeg by running the following command, which executes two popular video quality metrics:
ffmpeg -i encoded-video.mp4 -i reference-video.mp4 -lavfi "ssim;[0:v][1:v]psnr" -f null -

The final lines of the console output will contain:
[Parsed_ssim_0 @ 000000000039ad80] SSIM Y:0.984483 U:0.980458 V:0.980921 All:0.983219 (17.751712)
[Parsed_psnr_1 @ 0000000000398320] PSNR y:42.63 u:43.19 v:44.09 average:42.90 min:42.07 max:46.16

So, run the command once with the x264 output and once with x265 and compare with different x265 outputs, till you get similar measures. Of course, these metrics aren't perfect but you can use them as a rough guide to establish equivalence.

> **Comments:**
> **username_0**: Hmm interesting, may i ask why this scales doesn't correspond? Is a wanted design with a bigger amount of CRF values or could be considered this way because libx265 is still not mature enough in ffmpeg?  
> **username_0**: An addition to the previous comment. In ffmpeg documentation that you linked is said that x265 crf 28 is roughly equivalent to x264 crf 23. So, if generally the CRF of h265 are "better" qualitatively speaking than the x264 ones how is possible that the encode results of x265 is worst than x264 with same CRF ? Still a vlc bad decoding + libx265 too young?  
> **username_1**: 28 and 23 are the default CRF values of x265 and x264 respectively, hence the supposed equivalence. The short answer to the deviation from expected performance is that x265 is still under "heavy development". Nothing to do specifically with libx265 included with ffmpeg  See http://forum.doom9.org/showthread.php?t=170986 and http://compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf  
> **username_0**: I see, so because of this heavy development status even if I decide to move from ffmpeg and libx265 to another encoder the results will not change so much right? There aren't some commercial products based on x265 nowadays? Should have been already almost completed in all its parts!  
> **username_1**: If you look at the PDF I linked in the last comment, there are many encoders out there - most proprietary. My observation is confined to standalone x265 or its deployment, whether in ffmpeg or anything else. Those other encoders might be better - I haven't studied that PDF closely.  
> **username_2**: What's the x265 equivalent of x264 crf 18?  
> **username_1**: Around 21.......  

---

