libx265 quality worst than libx264 with the same bitrate

[ultron]

Hello, I was trying to encode a video that I have in h265 to see if I could keep a quality that was indistinguable from the original while being much smaller. To compare the quality of the original, I took a piece of it with ffmpeg copying the video stream and then encoded these with libx264 and libx265. The video piece is a mpeg1 encoding which bitrate of 1370kb/s of 352x288 pixels.
I decided to start the tests which a value that I thought was very conservative for the bitrate, that would give me virtually indistinguable results, and then I would reducing the bitrate a little bit each new encoding until reach the first noticeable loss of quality. I encoded with:
ffmpeg -y -i originalPiece.mpg -c:a copy -c:v libx265 -b:v 800k -pass 1 -f mp4 /dev/null && ffmpeg -i originalPiece.mpg -c:a copy -c:v libx265 -b:v 800k -pass 2 HEVC.mp4 with gave a video with bitrate of 1027kbps

But the quality was way inferior to the original. Then I decided to encode with libx264 using the same command above (exchanging libx265 by libx264) with gave a video with bitrate of 1031kbps, nearly equal, but of way superior quality.

The video is a tennis match and the hevc encoding clearly makes the ball dissapear a lot while in the air, especially in the faster balls, while in the original and the h264 encoding this doesn't happen with nearly the same intensity.

From what I read, From an old codec to libx264 reductions of up to 3 times are possible and then a 2 times reduction with libx265 over 264. So I was dreaming in keeping the quality close to the original, but with a bitrate not much superior a 200kbps and smaller than 250kbps.

What's going on here? What I can do to improve this disaster? I wanted to attach video pieces, but the attachment size is too limited.

[LoRd_MuldeR]

First of all, are you sure that your FFmpeg was built with latest libx265 version? x265 still is under active development and you definitely want the latest!

Furthermore, you may which to add the "-preset veryslow" option to the command-line (right after the "-c:v libx265" option), which will trade some encoding-speed for quality. And you may try adding the "-tune grain" option as well.

Also, 352x288 is an extremely small resolution. Maybe try a somewhat higher resolution video? HEVC/H.265 shines the most at high (e.g. "4K") resolutions.

Last but not least, re-encoding from a "low quality" source is always a bit problematic, as the compression artifacts caused by the different formats will add up - especially when you start with something archaic as MPEG-1.

The bitrate savings that, allegedly, can be achieved with "new" video formats (compared to "old" formats) only apply when both, the "new" and the "old" format, are allowed to encode directly from the original (uncompressed) source.

You can grab some of the most popular test clips, in lossless quality, from here:
http://media.xiph.org/video/derf/

[ultron]

Yes, I am pretty sure it is the latest version.

Unfortunately, lossless videos aren't what I have in my hands to work with and I don't think I ever will use one of them. Neither 4k videos. The vast majority will be between 320x240 and dvd resolution with, maybe, a few 720p and 1080p.

Anyway decided to test with a video of greater quality, a mpeg2 of 720x576 and a bitrate of 3747Kbps.

Re-encoded it with libx265 & 4 at 800kbps, with generated samples with 929 and 940kbps. libx265 image was worst in terms of the ghost that the ball leave behind, but neither was good enough.

The -tune grain parameter helped x265 to get rid of ghosting, but seemed to blur the image too much for my taste. On x264 may have blurred the image, but definitely didn't help to take care of ghosting nowehre near as well as libx265.

Preset veryslow helped both codecs a LOT and improved much the image, apparently leaving the encodings close to the original mpeg2's one. Unfortunately it also destroyed my poor core 2 duo 7500. libx265 with preset medium already brings my cpu close to the limit and with "veryslow" it's absolutely beyond doable. I think I got speed of about 0.04x and I think it is slight more than an order of magnitude slower than with standard settings. Even with libx264 my cpu is brought to it's absolute limit and might be slower than x265 with normal setings

I can barely image what would be to encode a 4K with -preset veryslow. I think may take months on my cpu to do it.

How much "preset slower" it is compared with "medium"? To be worth to test it would have to be less than twice as slow than medium which I certainly doubt.

Maybe tunning some few specific parameters that take part of -preset would help to reduce the encoding time while leaving the image quality gains?

Is there other codecs that I should look for?

Thanks for the answer

[dipje]

In a very small nutshell, h265 gains a lot of the improvement in bigger search areas and matching more of the screen. The lower the resolution the less it can win.
The parameters are far from tuner for a low resolution like that. And then it's an already compressed source.

Also, a lot of work was done on the presets and parameters tweaking, and im pretty sure values like that dont transfer to ffmpeg directly.

I did tests with lossless full HD sources recently and x265 was definitely 'more pleasing to watch' compared to the same bitrates.

Once you up the bitrates for x264 enough that it isn't struggling or starved for bitrate it changes a bit. Once x264 has enough bitrate to not show compression artifacts it tends to keep a bit more fine detail compared to x265. But this is once the bitrates come really high !

And there have been huge advances in x265 small detail retention in the last few months , which you won't use I'd you stick to preset medium or faster.

Don't compare compressors based on recompression of extreme small VHS era resolutions.
I understand that it's YOUR use case do you figure out what works best for you. But posting a thread with a title like that and doing a test like this is just plain misleading and a bit trolling.

[LoRd_MuldeR]

Preset veryslow helped both codecs a LOT and improved much the image, apparently leaving the encodings close to the original mpeg2's one. Unfortunately it also destroyed my poor core 2 duo 7500.

Well, nothing is for free. Improved "quality per bit" ratio comes at the cost of slower encoding speed. You can't expect wonders from an old and relatively "weak" (even for its time) CPU.

If you regularly encode videos, you definitely want (at least) a Quadcore processor. Encoders like x264 and x265 scale very well to a large number of cores. So, N-times more processor cores usually give almost an N-times speed-up!

SIMD also helps a lot, so you'd want a processor with AVX or even AVX2 support nowadays.


How much "preset slower" it is compared with "medium"? To be worth to test it would have to be less than twice as slow than medium which I certainly doubt.

Maybe tunning some few specific parameters that take part of -preset would help to reduce the encoding time while leaving the image quality gains?

The presets have already been carefully tuned by the developers to give the best possible "speed vs. quality" trade-off – at various different "speed levels".

(You can think of the presets as different points on the optimal "speed vs. quality" curve)

There is no "hidden" option that magically makes things run a lot faster without sacrificing any quality. If such option existed, you can be sure it would already have been incorporated into the presets ;)

Anyhow, you could try fine-tuning the Psy options (http://x265.readthedocs.io/en/default/cli.html#psycho-visual-options) according your personal preferences. But that should mostly be covered by the "--tune" system (https://x265.readthedocs.io/en/default/presets.html#tunings) already.


Is there other codecs that I should look for?

If you want H.264 (AVC) or H.265 (HEVC), then libx264 and libx265 already are the highest quality encoders you can get.

There are "hardware" encoders available, like NVENC and VCE, which encode way faster - but quality isn't anywhere close to the best "software" encoders. And it seems that quality is you primary concern.

Other video formats that you could give a try include VP9 (https://trac.ffmpeg.org/wiki/Encode/VP9) ("WebM") or Xiph Daala (https://wiki.xiph.org/Daala_Quickstart) (still experimental). Note, however, that libx265 was recently found to be ~20% more efficient than VP9:
https://forum.doom9.org/showthread.php?t=173858

[ultron]

I understand that it's YOUR use case do you figure out what works best for you. But posting a thread with a title like that and doing a test like this is just plain misleading and a bit trolling.

I think a title like "Is libx265 good for compressed, low resolution videos?" would have been more appropriate. But I can't think of anything in place of the tests that I did, execept maybe to not mention them.
Then what would you suggest in both cases, especially the test cases?

You can't expect wonders from an old and relatively "weak" (even for its time) CPU.

I don't agree about weak for it's time. As far as I remember the only desktop processors that were significantly faster at time were the few Amd and Intel quad cores.

If you regularly encode videos, you definitely want (at least) a Quadcore processor.

Unfortunatelly, that would defeat all the purpose of what I am doing, that is to shrink all my videos without losing much quality so as to not buy a new hard drive. I had a 250GB that broken and was left with a 40GB one.

Anyhow, you could try fine-tuning the Psy options according your personal preferences. But that should mostly be covered by the "--tune" syste

Thanks, will give a look.

And it seems that quality is you primary concern.

It's space, followed by quality, then speed. If I wasn't limited by space, I might even do the opposite and re-encode some h264 videos to mpeg2 so as be able to play then on standalone dvd player

Other video formats that you could give a try include VP9 ("WebM") or Xiph Daala (still experimental). Note, however, that libx265 was recently found to be ~20% more efficient than VP9:

But that would be on uncompressed source right? I will probably give a look at them anyway.

[LoRd_MuldeR]

I don't agree about weak for it's time. As far as I remember the only desktop processors that were significantly faster at time were the few Amd and Intel quad cores.

Well, Core2 Quads were available at that time. And, with libx264 or libx265, a Quadcore gives about ~2x the throughput compared to a Dualcore of the same generation.


Unfortunatelly, that would defeat all the purpose of what I am doing, that is to shrink all my videos without losing much quality so as to not buy a new hard drive. I had a 250GB that broken and was left with a 40GB one.

Honestly, if that is your reason, then consider getting a larger HDD and not re-encoding at all!

Re-encoding always reduces quality, to some degree, unless you use a 100% lossless format. This called "generation loss". Also, re-encoding costs a lot of time (and energy). It's always best to not re-encode at all.

You can get a 4 TB drive for ~125 bucks these days, which is like ~3 cent per GB.


But that would be on uncompressed source right?

Yes, usually people compare video formats (or encoders) by encoding from the same original source - usually a high-quality uncompressed tests clip. You don't encode to the one format and, from there, re-encode to the other.

But since your goal is to re-encode your existing MPEG-1 files, you could try re-encoding them to VP9 or Daala rather than to H.264 or H.265. Just to get a "point of comparison".

(But again: If format "A" was found to be x percent more efficient than format "B" when both formats are allowed to encode directly from an uncompressed original source, then you certainly will get significant less than x percent savings if you first encode to format "B" and then re-encode to format "A" from there. That's because the compression artifacts introduced by format "A" and those introduced by format "B" are going to add up in the latter case)

[WhatZit]

Preset veryslow helped both codecs a LOT and improved much the image, apparently leaving the encodings close to the original mpeg2's one. Unfortunately it also destroyed my poor core 2 duo 7500. libx265 with preset medium already brings my cpu close to the limit and with "veryslow" it's absolutely beyond doable. I think I got speed of about 0.04x and I think it is slight more than an order of magnitude slower than with standard settings. Even with libx264 my cpu is brought to it's absolute limit and might be slower than x265 with normal setings.

Install ffmpeg 3.2.2 Nightly 20170112, 10-bit x265 v2.2+22, and MKVToolnix v9.7.1.

Use this command:

ffmpeg -i original.mpeg -f yuv4mpegpipe - | x265 --preset fast --crf 23 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing --y4m - -o output.hevc

Then mux the audio stream from original.mpeg with the video stream in output.hevc into a new .MKV using MKVToolNix GUI (MKVMerge).

This converted this file:

General
Format : MPEG-PS
File size : 10.6 MiB
Duration : 1 min 2 s
Overall bit rate : 1 411 kb/s

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 1
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=15
Duration : 1 min 2 s
Bit rate : 1 150 kb/s
Width : 352 pixels
Height : 240 pixels
Display aspect ratio : 16:10
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.454
Time code of first frame : 00:00:00:01
Time code source : Group of pictures header
GOP, Open/Closed : Open
Stream size : 8.70 MiB (82%)

Audio
ID : 192 (0xC0)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 224 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Delay relative to video : 153 ms
Stream size : 1.68 MiB (16%)


into this file:

General
Format : Matroska
Format version : Version 4 / Version 2
File size : 5.74 MiB
Duration : 1 min 3 s
Overall bit rate : 755 kb/s
Encoded date : UTC 2017-01-14 07:01:37
Writing application : mkvmerge v9.7.1 ('Pandemonium') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5

Video
ID : 2
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L2@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 3 s
Bit rate : 529 kb/s
Width : 352 pixels
Height : 240 pixels
Display aspect ratio : 16:10
Original display aspect ratio : 16:10
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.209
Stream size : 4.03 MiB (70%)
Writing library : x265 2.2+22-20217c8af8ac:[Windows][GCC 6.2.0][64 bit] 10bit
Language : English
Default : Yes
Forced : No

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : A_MPEG/L2
Codec ID/Hint : MP2
Duration : 1 min 3 s
Bit rate mode : Constant
Bit rate : 224 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 spf)
Compression mode : Lossy
Delay relative to video : 153 ms
Stream size : 1.69 MiB (29%)
Language : English
Default : Yes
Forced : No


with "similar" quality to my eyes, using very little CPU power.

You might have to tweak the CRF & preset to suit your own eyes. As others have pointed out, using x265 with such low resolutions robs it of any opportunity to perform all that efficient compression you may have read about.

[ultron]

Honestly, if that is your reason, then consider getting a larger HDD and not re-encoding at all!

Re-encoding always reduces quality, to some degree, unless you use a 100% lossless format. This called "generation loss". Also, re-encoding costs a lot of time (and energy). It's always best to not re-encode at all.

You can get a 4 TB drive for ~125 bucks these days, which is like ~3 cent per GB.


You are american right? First that's probably the value in US and a maybe a few other countries. But hardware isn't extremely cheap where I live, it's extremely expensive. And even if was as cheap as in the US, I am not willing to expend nowhere near 125$ on it.

Your comment on energy was vital. I will underclock my cpu and do the encoding only when I am already using the pc. Won't be able to use libx264 with preset -veryslow anymore, unfortunatelly

Yes, usually people compare video formats (or encoders) by encoding from the same original source - usually a high-quality uncompressed tests clip. You don't encode to the one format and, from there, re-encode to the other.

But since your goal is to re-encode your existing MPEG-1 files, you could try re-encoding them to VP9 or Daala rather than to H.264 or H.265. Just to get a "point of comparison".

(But again: If format "A" was found to be x percent more efficient than format "B" when both formats are allowed to encode directly from an uncompressed original source, then you certainly will get significant less than x percent savings if you first encode to format "B" and then re-encode to format "A" from there. That's because the compression artifacts introduced by format "A" and those introduced by format "B" are going to add up in the latter case)

Will look into VP9 and Daala as soon as I finish my current encoding and try WHatZip suggestion, if possible.

[ultron]

Then mux the audio stream from original.mpeg with the video stream in output.hevc into a new .MKV using MKVToolNix GUI (MKVMerge).


Can't use ffmpeg for that? I cannot install this MKVmerge.

This converted this file:

General
Format : MPEG-PS
File size : 10.6 MiB
Duration : 1 min 2 s
Overall bit rate : 1 411 kb/s

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 1
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=15
Duration : 1 min 2 s
Bit rate : 1 150 kb/s
Width : 352 pixels
Height : 240 pixels
Display aspect ratio : 16:10
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.454
Time code of first frame : 00:00:00:01
Time code source : Group of pictures header
GOP, Open/Closed : Open
Stream size : 8.70 MiB (82%)

Audio
ID : 192 (0xC0)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 224 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Delay relative to video : 153 ms
Stream size : 1.68 MiB (16%)


into this file:

General
Format : Matroska
Format version : Version 4 / Version 2
File size : 5.74 MiB
Duration : 1 min 3 s
Overall bit rate : 755 kb/s
Encoded date : UTC 2017-01-14 07:01:37
Writing application : mkvmerge v9.7.1 ('Pandemonium') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5

Video
ID : 2
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L2@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 3 s
Bit rate : 529 kb/s
Width : 352 pixels
Height : 240 pixels
Display aspect ratio : 16:10
Original display aspect ratio : 16:10
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.209
Stream size : 4.03 MiB (70%)
Writing library : x265 2.2+22-20217c8af8ac:[Windows][GCC 6.2.0][64 bit] 10bit
Language : English
Default : Yes
Forced : No

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : A_MPEG/L2
Codec ID/Hint : MP2
Duration : 1 min 3 s
Bit rate mode : Constant
Bit rate : 224 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 spf)
Compression mode : Lossy
Delay relative to video : 153 ms
Stream size : 1.69 MiB (29%)
Language : English
Default : Yes
Forced : No


with "similar" quality to my eyes, using very little CPU power.

You might have to tweak the CRF & preset to suit your own eyes. As others have pointed out, using x265 with such low resolutions robs it of any opportunity to perform all that efficient compression you may have read about.

This 10 bit really can make a difference? In a simple test I did, I didn't note much difference between them. Will do a few more tests now

[LoRd_MuldeR]

You are american right?

Nope, not at all ;)

But I took the price for a standard 4 GB HDD from Amazon.com. At my location, prices for HDD's are within the same range though, when converted from local currency to US-Dollar.

..which is not really surprising, since pretty much all HDD's are manufactured in Southeast Asia these days.

(Remember the Thailand flooding that caused HDD's to be hardly available, globally, for several months? So, regardless of where you live, the HDD's are always imported from there)


First that's probably the value in US and a maybe a few other countries. But hardware isn't extremely cheap where I live, it's extremely expensive. And even if was as cheap as in the US, I am not willing to expend nowhere near 125$ on it.

Your comment on energy was vital. I will underclock my cpu and do the encoding only when I am already using the pc. Won't be able to use libx264 with preset -veryslow anymore, unfortunatelly

Well, on your current hardware, you will either have to use "quick and dirty" encoding settings, which results in subpar quality (provided a bitrate reduction is desired), or you will have to wait for like forever.

Since both options are inacceptable, some sort of system upgrade will probably be inevitable.

Compered to what you'd have to spend for a modern CPU (plus motherboard, RAM, etc) that can do proper "high quality" video encoding in reasonable time, the price for a larger HDD is pretty much negligible.

Plus: With a larger HDD you could probably avoid re-encoding completely, which saves you a lot of work and time (and quality).

[kuchikirukia]

Do you have a DVD burner? It doesn't sound like you have a lot of videos, and you can pick up a spindle of 100 for under $20 in most places.

[Neavrie]

@ultron
To perform two-pass encoding with ffmpeg and libx265 use -x265-params pass=1/2 instead of -pass 1/2. With command line from your first post you are using ABR mode.

[ultron]

@ultron
To perform two-pass encoding with ffmpeg and libx265 use -x265-params pass=1/2 instead of -pass 1/2. With command line from your first post you are using ABR mode.

Thanks for noting it. Using it I realized that the second pass take the same amount of time. With x264 the first pass is much faster, with vp9 the encoding guide that I read recommends to use a much faster speed setting in pass 1 (speed 4), than in pass two (speed 1). Can I do something similar with x265 so as do not duplicate the encoding time using two pass encoding ?

[sneaker_ger]

-x265-params pass=1:no-slow-firstpass=1

https://x265.readthedocs.io/en/default/cli.html#cmdoption--slow-firstpass
Also see the two options below that one. I haven't tested them as they are kinda new but they may speed multipass up a bit more.

[ultron]

Thanks, it's working fine.

[kolak]

You start with semi decent quality, use low bitrates with fast presets and complain about final quality? So much effort for such a small end result. Just store your original files- open few gmail accounts (then share assets between them, so you can access from 1) and store them for free in the cloud where you don't have to worry about disks problems etc. Google will even make you some proxy for free out of your masters.

How are you going to store your new files? On HDDs, single copy? One day you maybe very surprised, when disk will be dead and all your precious videos gone for good.
Archive on a single disk is not an archive, it's just an illusion that you have an archive :)

[ultron]

You start with semi decent quality, use low bitrates with fast presets and complain about final quality? So much effort for such a small end result. Just store your original files- open few gmail accounts (then share assets between them, so you can access from 1) and store them for free in the cloud where you don't have to worry about disks problems etc. Google will even make you some proxy for free out of your masters.

How are you going to store your new files? On HDDs, single copy? One day you maybe very surprised, when disk will be dead and all your precious videos gone for good.
Archive on a single disk is not an archive, it's just an illusion that you have an archive :)

I don't have choice about the original quality of the videos (most of time) since most of it are tennis matches, and most are old, from before high definition became norm.

The gmail is an option, but my internet is slow, so it would take a lot of time. Anyway, it would be foolishness to let everything stored in my old HD waiting for it to crash, so I keep copies on two pen drives and when/if they became full, I will move to recordable dvd as was suggested here.

Anyway, a lot of time has passed since my original post, and I got a good result reencoding a tennis match with xlib265. Unfortunately, it required slower and veryslow settings to get good enough results, which makes it unsuitable for most tennis matches and my old cpu.

And that was before I read the post where I was alerted that I wasn't doing two pass encoding correctly. I suspect that which two pass encoding I may be able to get good enough results with slow preset, which would make it suitable to far more cases.

And I suspect that because in the test that I did, a movie of 576x240, my two pass encoding which slower preset got a more pleasant result than x264 with veryslow preset and a higher bitrate.

[kolak]

Even with slow internet you can keep sending to gdrive every night even for months.
Transcoding with x265 on older machine will take you not much less :)
At least you are happy with quality now.

Burned DVDs are not very good archive format. Some of them (if you buy cheap ones) go bad (physically) even after 5 years. It's also very "gentle" format as for archiving needs. BDs are more robust due to way better coating.

[iAvoe]

Generally, you need --ctu 16, because your video's resolution is too small and x264 is designed for that.