8

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?

Improve this question

1 Answer 1

Reset to default
8

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.

Improve this answer
7
  • 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
    Commented Oct 21, 2015 at 19:15
  • 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
    Commented Oct 21, 2015 at 19:31
  • 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 forum.doom9.org/showthread.php?t=170986 and compression.ru/video/codec_comparison/hevc_2015/…
    – Gyan
    Commented Oct 21, 2015 at 19:35
  • 1
    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
    Commented Oct 21, 2015 at 20:05
  • 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
    Commented Oct 22, 2015 at 7:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.