Jan 252017
H.265/HEVC logo

1.) Introduction

After doing a [somewhat proper comparison between x264 and x265] a while back, I thought I’d do another one at extremely low bitrates. It reminded me of the time I’ve been using ISDN at 64kbit/s (my provider didn’t let me use CAPI channel aggregation for 128kbit/s), which was the first true flat rate in my country. ‘Cause I’ve been thinking this:

“Can H.265/HEVC enable an ISDN user to stream 1080p content in any useful form?” and “What would H.264/AVC look like in that case?”

Let me say this first: It reaaally depends on how you define “useful”. :roll:

Pretty much nobody uses ISDN these days, and V.9x 56kbaud modems are dying out in the 1st world as well, so this article doesn’t make a lot of sense. To be fair, I didn’t even pick encoding settings fit for low-latency streaming either, nor are my settings fit for live encoding. So it’s just for the lulz, but still! I wanted to see whether it could be done at all, in theory.

To make it happen, I had to choose extremely low bitrates not just for video, but audio as well. There are even subtitles included in my example, which are present in Matroska-style zlib-compressed [.ass] format, so compressed text essentially.

For the audio part, I chose the Fraunhofer FhG-AAC encoder to encode to the lowest possible constant bitrate, which is 8kbit/s HEv2-AAC. That’s a VoIP-focused version of the codec targeted at preserving human speech as well as possible at conditions as bad as they get. And yes, it sounds terrible. But it still gets across just enough to be able to understand what people are saying and what type of sounds are occurring in a scene. Music and most environmental sounds are terrible in quality, but they are still discernible.

For video, I picked a 2-pass ABR mode with a 50kbit/s target bitrate, which is insanely low even for the Anime content I picked (my apologies, Mr. “[Anime is not what everyone watches]”, but yes, I picked Anime again). Note that 2D animated content is pretty easy on the encoders in this case, so the results would’ve likely been a lot worse with 1080p live action content. As for the encoder settings, you can find those [down below] and as for how I’m taking the screenshots, I’ll spare you those details, they’re pretty similar to the stuff shown in the link at the top.

Before we start with the actual quality comparison, I should mention that my test results actually overshot their target, so they’re really unsuitable for live streaming even in the ISDN case. I just didn’t care enough for trying to push the bitrate down any further. Regular streaming would still be possible with my result files, but not without prebuffering. See here:

$ ls -hs *.mkv
2.6M Piaceː Watashi no Italian - Episode 02-H.264+HEv2AAC-V50kbit-A8kbit.mkv
2.0M Piaceː Watashi no Italian - Episode 02-H.265+HEv2AAC-V50kbit-A8kbit.mkv
 76M Piaceː Watashi no Italian - Episode 02.mkv
$ for i in {'Piaceː Watashi no Italian - Episode 02.mkv','Piaceː Watashi no Italian - \
Episode 02-H.264+HEv2AAC-V50kbit-A8kbit.mkv','Piaceː Watashi no Italian - \
Episode 02-H.265+HEv2AAC-V50kbit-A8kbit.mkv'}; do mediainfo "$i" | grep -i "overall bit rate"; done
Overall bit rate                         : 2 640 kb/s
Overall bit rate                         : 88.6 kb/s
Overall bit rate                         : 69.2 kb/s

The first one is the source (note: From [Crunchyroll], legal to watch and record in my country at this time), the second my x264 and the third my x265 versions. Let’s show you the bitrate overshoot of just the video streams in my versions:

$ for i in {'Piaceː Watashi no Italian - Episode 02-H.264+HEv2AAC-V50kbit-A8kbit.mkv','Piaceː \
Watashi no Italian - Episode 02-H.265+HEv2AAC-V50kbit-A8kbit.mkv'}; do mediainfo \
--Output="Video;%BitRate/String%" "$i"; done
71.1 kb/s
51.6 kb/s

So as you can see, x264 messed up pretty big, overshooting by 21.1kbit/s (42.2%), whereas x265 almost landed on target, overshooting by a mere 1.6kbit/s (3.2%) overall. And still… well… Let’s give you an overview first (as usual, click to enlarge images):

2.) Quality comparisons

Note that the color shown in those thumbnails is not representative of the real images, this has been transformed to 256 color .png to make it easier to download (again, if your browser supports it, .webp will be loaded instead transparently). This is just to show you some basic differences between what x264 and x265 are able to preserve, and what they are not. Also, keep in mind, that “~50kbit/s nominal bitrate” means 71.1kbit/s for x264 and 51.6kbit/s for x265!

Overall, x264 fucks up big time. There are frames with partial macroblock drops and completely blank frames even! Also, a lot of frames lose their color either partially or completely as well, making them B/W. And that’s given that x264 even invested 42.2% more bitrate than what I aimed for!

x265 has no such severe issues, all frames are completely there in full color, and that at a bitrate reasonable close to the target. Let’s look at a few interesting cases side by side:

Scene 1 (left: x264, middle: x265, right: source file):

There are some indications of use of larger CTUs (coding tree unit, H.265s’ replacement for macroblocks) in x265s’ case, which is supposed to be one of its strong points, especially for very large resolution encoding (think: 4K/UHD, 8K). While larger blocks can mean loss of detail in that area, it’s ok for larger areas of uniform color, which this Anime has a ton of. H.264/AVC can’t do that so well, because the upper limit for a macroblocks’ size is rather low with 16×16 pixels. You can see the macroblock size pretty clearly in the blocky frame to the left. You need to look a bit more carefully in x265s’ case, but there are a few spots where I believe it can be seen as well. In my case the CTU size for x265 was 32×32px.

Hm, maybe --ctu 64 would’ve been better for this specific case, but whatever.

Lets look at two more mostly color-related comparisons:

Scenes 2 & 3 (left: x264, middle: x265, right: source file):


In the first case it seems as if x264 is trying to preserve shades of green more than anything, but in the second case, something terrible happens. There is a lot of red in the scene before this one, and there is quite some red on those can labels as well. It seems x264 doesn’t know where to put the color anymore, and the reds bleed almost all over the frame. And it stays like that for the entire scene as well, which means for several seconds. The greens and browns are lost. Block artifacts are excessive as well, but at least x264 managed to give us whole frames here, with some color even.

Well, the color kinda went everywhere, but uhm, yeah…

Two more:

Scenes 4 & 5 (left: x264, middle: x265, right: source file):


I really don’t know what’s with x264 and the reds. Shouldn’t green have priority? I mean, not just in the chroma subsampling, but in encoding as well? But red seems what x264 drops last, and it happens more than once. Given the detail and movements in that last part, even x265 fails though. Yes, it does preserve more color, but it doesn’t come remotely close to the source at this bitrate.

And that other frame with the cuteness overload? There are a lot like those, where x264 just kinda panics, drops everything it has and then frantically tries to (re?)construct the current frame, sometimes only partially until the next I-frame arrives or so.

So that’s it for my quick & dirty “ultra low bitrate” comparison between x264 and x265, at pretty taxing encoding settings once again.

3.) Additional information

x264 encoding settings:

$ mediainfo Piaceː\ Watashi\ no\ Italian\ -\ Episode\ 02-H.264+HEv2AAC-V50kbit-A8kbit.mkv | grep -i \
"encoding settings"
Encoding settings                        : cabac=1 / ref=16 / deblock=1:-2:0 / analyse=0x3:0x133 / \
me=umh / subme=10 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 \
/ 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=18 / \
lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / \
constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / \
open_gop=1 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / \
rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=50 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=81 \
/ qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:0.60

x265 encoding settings (note: 10 bits per color channel were chosen, same as for x264):

$ mediainfo Piaceː\ Watashi\ no\ Italian\ -\ Episode\ 02-H.265+HEv2AAC-V50kbit-A8kbit.mkv | grep -i \
"encoding settings"
Encoding settings                        : cpuid=1049087 / frame-threads=3 / wpp / pmode / pme / \
no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 \
/ level-idc=0 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / no-repeat-headers / \
annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / \
keyint=250 / bframes=16 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / \
lookahead-slices=0 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / \
max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=1 / signhide / \
no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 \
/ limit-refs=1 / limit-modes / me=3 / subme=4 / merange=57 / temporal-mvp / weightp / weightb / \
no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=6 / no-early-skip / rskip / \
no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=1.60 / \
psy-rdoq=5.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / \
bitrate=50 / qcomp=0.75 / qpstep=4 / stats-write=0 / stats-read=2 / stats-file=265/v.stats / \
cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / \
zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / \
videoformat=5 / range=1 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 \
/ max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / \
slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05

x264 version:

$ x264 --version
x264 0.148.x
(libswscale 3.0.0)
(libavformat 56.1.0)
built on Sep  6 2016, gcc: 6.2.0
x264 configuration: --bit-depth=10 --chroma-format=all
libx264 configuration: --bit-depth=10 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat license: nonfree and unredistributable
WARNING: This binary is unredistributable!

x265 version:

$ x265 --version
x265 [info]: HEVC encoder version 2.2+23-58dddcf01b7d
x265 [info]: build info [Linux][GCC 6.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

Encoding & testing platform:

$ uname -sr
Linux 2.6.32-573.8.1.el6.x86_64
$ cat /etc/redhat-release 
CentOS release 6.8 (Final)
$ cat /proc/cpuinfo | grep "model name" | uniq
model name	: Intel(R) Core(TM) i7 CPU       X 980  @ 3.33GHz

4.) Answers

Q: “Can H.265/HEVC enable an ISDN user to stream 1080p content in any useful form?

A: It can probably stream something that at least resembles the original source in a recognizable fashion, but… whether you can call that “useful” or not is another thing entirely…

Q: “What would H.264/AVC look like in that case?”

A: Like shit! :roll:

CC BY-NC-SA 4.0 x264 vs. x265: 1080p ultra low bitrate comparison by The GAT at XIN.at is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

  12 Responses to “x264 vs. x265: 1080p ultra low bitrate comparison”

  1. Removing grain increases the picture quality for a given bandwidth and requires a visual assessment before the transcode of a raw BR stream.

    After coding approximately 2500 streams, all at 2K or 4K then the following is now my standard starting point for 2K content, using version 2.6

    Using 2-pass ABR for 2K:

    – For movies: 1600 to 2000 kb/s for 2K at full 1080 height, and 1300 to 1500 kb/s for 2K at 800 height

    – For TV shows: 1100 kb/s for 2K at full 1080p height, and 450 kb/s to 900 kb/s for 720p height

    LINE CODE, assuming 10bit x265:

    –dither –deblock -3:-2 –aq-mode 3 –qcomp 0.8 –nr-intra NUMBER –nr-inter NUMBER


    No grain: use “no grain” setting and delete –nr-intra and –nr-inter entries

    i.e.: –dither –deblock -4:-3 –aq-mode 3 –qcomp 0.8

    Slightest of grain: use “no grain” and set NUMBER to 10

    i.e.: –dither –deblock -3:-2 –aq-mode 3 –qcomp 0.8 –nr-intra 10 –nr-inter 10

    Moderate grain: use “grain” and set NUMBER to 30

    i.e.: –dither –deblock -3:-2 –aq-mode 3 –qcomp 0.8 –nr-intra 30 –nr-inter 30

    Hi Grain: use “grain” and set NUMBER to 100:

    i.e.: –dither –deblock -3:-2 –aq-mode 3 –qcomp 0.8 –nr-intra 100 –nr-inter 100

    Very high grain: use “grain” and set NUMBER to 300 and remove deblocking:

    i.e.: –dither –aq-mode 3 –qcomp 0.8 –nr-intra 300 –nr-inter 300

    I hope this helps!

    • Hello James,

      Interesting, thanks. I do have a few grainy sources where I’ve done little but use --tune grain and elevated bitrates. I’ve gotta say though, I prefer to maintain the grain if possible at acceptable bitrates (≤5000kbit for 16:9 1080p or 21:9 800p). I’ve had trouble doing that especially for slight, low-contrast grain. I’m still looking for some settings that can deal with the preservation of such grain without washing it out too quickly.

  2. Q1 Changing the qcomp values changes anything?
    Q2 Does Medium and very slow yield same video quality?
    Q3 What can I use to convert a PCM audio to FLAC audio without any change (the graph in spek) ?
    Q4 Can I convert SDR video into HDR?
    Q5 Should I keep using crf or should I use Avg bitrate to get more quality?

    The tests you do are truly amazing and I appreciate the fact that these tests really helped me learn a lot.


    • Hello Kiyo,

      1. I cannot really answer question 1, as I never mess with the quantizer manually. Pushing the curve compression factor down will penalize complex (high motion) scenes and benefit static ones more. For ultra-low bitrates, lower --qcomp values have been suggested, but I haven’t tested this myself.
      2. Of course not! You can compare the preset settings [here] (x264) and [here] (x265).
      3. ffmpeg with support for PCM and libflac (which should be the default) for instance. Sample command line: ffmpeg -i input.wav output.flac, done. ffmpeg can also read 64-bit Sony Wav64 when compiled with the w64 demuxer by the way, so very large .w64 files are fine too.
      4. No. You’ll just lack the dynamic range. An analogy: It’s like changing an 8-bit image to 24-bit. It wouldn’t magically transform it into nice true color.
      5. That depends on your requirements. Do you need to maintain a certain quality level (however high or low that may be)? Then it’s --crf for you. Do you need to maintain constant file sizes? Then it’s average --bitrate. Do you need to adhere to strict bandwidth requirements, like with online streaming? Then it’s constant --bitrate (amongst other things, if it’s live video). You need to know what you want/need first.
  3. Love this mate. I was looking for this exact information :D see I have a 3G connection with 2GB of data, but after those 2GB it throttles down to 0.1Mbps.

    I want to encode video on a computer at my home and send it to the 3G connection. Downloading 1GB of data takes a day currently.. But with some serious encoding I could pretty much stream in real time :)

    • Hey Jason!

      Although – as you can clearly see here – it would still look awful! ;) I mean, 0.1Mbps would put you at… what actually? Either 8kiB/s or 16kiB/s?

      I would suggest downscaling the content to something like 480p (ffmpeg can do that for you) and then transcoding it to H.265/HEVC, this might result in something more usable. Also, you may wish to invest at least a little bit of additional bitrate in audio as well, I mean, 8kbit/s HEv2-AAC sounds reaaally horrible. Like worse than a phone call in the 50s.

      Also: If you choose to go more low-res, you can encode faster even when using more taxing settings at the same bitrate. So that could be a good choice, especially if your client machine on 3G is a phone or tablet (and not a device with a large screen).

  4. I just can’t wait for x269, imagine what that codec will be able to do! %-)

    • Joking aside, maybe the free codec AV1 will really beat x265. But people are always promising us heaven and earth before any actual releases of the code. For now, I’ve shifted parts of my encoding workloads to H.265/HEVC and it’s working rather well. Next step: HDR support (which I will be looking into soon).

      I’m currently using it for 4K/UHD live action stuff, because I can keep the bitrate much lower and H.265s’ larger CTUs are a good fit for high resolutions (2 hours take me about 12-16 days to encode on an Intel Xeon X5690 or AMD FX-9590). I’m also using it for SDTV, because it’s fast enough encoding smaller files at very low bitrates, and is still more efficient (using smaller CTUs there). The only content I’m not using it for very often is 720p and 1080p. At my extreme settings, my CPUs simply can’t handle the load given the large amount of material.

      I am planning to get a little Linux or FreeBSD encoding box in the forseeable future though, wanna give AMDs’ 16-core Ryzen a try! :) I hope there will be Mini-ITX boards for that, like for socket 2011-3 by ASRock. That’d be awesome. 16 cores, 32-64GiB RAM, a SSD and Ethernet in a small, black box’s all I need. :)

      • I could benchmark a xeon e3-1225 v5 for you, and/or a core i3-7100. Maybe those avx instructions work with that encoder, but that amd ryzen will also probably have those avx instructions.

        But what are you encoding? Something you made yourself, or just stuff from the internets that can be re-encoded with x265 to much smaller sizes?

        BTW, do you know any good (windows) programs for anything video-related, apart from the commandline utilities? I know about shotcut, handbrake and tmpgenc.

        • I’m currently working on a new cross-platform 64-bit x265 benchmark project that includes a C/C++/asm bootstrapper for UNIX-style operating systems, including support for Linux, FreeBSD (+TrueOS), OpenBSD, NetBSD and DragonFly BSD UNICES as well as Solaris and Haiku OS, also MacOS X and Windows…

          …so maybe we should wait until it’s ready. :) Been working on it for months now, cross-platform support sure is a pain in the arse.

          As for the tools, I’m afraid I can’t help you. I’ve shifted almost everything to the command line, and I’m working even on headless systems. For my transcoding work, I’m using XP x64, Linux and FreeBSD UNIX now, and the terminal is the common denominator (with GoW/GNU on Windows and clink on the cmd).

          Reason is that I wanted to streamline things. Essentially, I wanted my stuff to work in the same way on Windows, Linux and UNIX. So, all command line! If you don’t like that, then maybe something like Handbrake is good enough? Where needed, it can be tuned manually as well, so it should be fine?

          About H.265: I’m using it for SDTV stuff, because I can encode those videos in finite time at very low bitrates without losing any quality, and also for 4K/UHD stuff, because it’s very well suited for very high resolutions (although with my settings, transcoding 2h of 4K stuff takes about 10-14 days or so).

          In some cases, I also encode 1080p to H.265/HEVC, for those rare videos that are really precious to me. In some weird way, spending a ton of CPU time on them to preserve almost all of their quality despite lower bitrates is like… paying them some respect or something. ;)

          I sometimes do that for very expensive Anime Blu-Rays I got from Japan… Other types of content that I use regular H.264/AVC for are normal Blu-Rays or Anime Fansubs off the Internet, or old videos that were compressed with inefficient codecs such as MS MPEG4, DivX/XviD, etc.

          My goal would be to migrate everything to H.265 or x265, mostly because it can preserve more information per byte at the same bitrate when compared to x264 at similar settings.

  5. COOL! thanks for the ultra low comparison. looking everywhere for it.

    please do an updated 2017 version of 2.x codec if allows, with cartoon and real action 1080p sources.

    looking forward to it hopefully!

    • Hey Maome,

      I don’t have a lot of time on my hands right now, so I don’t think that I can do it in the near time (at least not this week I assume). Of course, if I do do it again, I’ll use most current versions for both x264 as well as x265. As for the live action part I guess I could just grab a scene out of some free Blender movie, like “Tears of Steel” (I’m basing my new x265 benchmark project on an 8K upscale of that).

      You’ll have to be a bit patient though. If I can find the time, I’ll create a new post and add a link here as well (so that you get an eMail notification when it’s ready).

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">