x265 HEVC Encoder

[LigH]

There are several tunings for x264; but only few tunings for x265, and it is not really certain if they already make any difference at all.

[sKRUVEN]

Here are some frames. http://speedy.sh/A6Bjh/CrowdRun-2160p50-CgrLevels-MASTER-SVTdec05.rar

x265 do look cleaner, however it looks less true to the original then the x264 one. So what do you guys think? Is it that x265 is tuned to be less noisy or am I doing something wrong?

LigH how did your tests look? Did x265 retain more grain than x264?

[x265_Project]

Oh, that might be it, the source contains alot of film grain and the x265 version looks denoised so there is less grain and detail compared to the x264 one. Will try those tweeks and see if it helps to retain the detail.

Edit. That did nothing, the one with --tune ssim and --aq-mode 2 look exactly the same as the old one. Don't even know if it worked or that it default ssim since the new file has the exact same file size.

--tune ssim is on by default

[foxyshadis]

When it comes to recompressing with an immature codec, start with the stuff you care the least about yet takes up the most extra space. Ridnacs and other space-visualizing tools are a great help. x265 may not quite be mature yet, but it's definitely juvenile level (without even writing angsty Twilight fan-fiction subtitles), seeing lots of steady quality gains, and the time you buy archiving less-important stuff lets you wait a little bit longer for the best. Of course it's tempting to concentrate on your favorite movies ever first, but you'll just want to re-do them every time the codec improves.

Obviously the easiest way to save space and time is to decide that hey, I'm never going to watch that movie again in my life, and chuck it. :D

[x265_Project]

Here are some frames. http://speedy.sh/A6Bjh/CrowdRun-2160p50-CgrLevels-MASTER-SVTdec05.rar

x265 do look cleaner, however it looks less true to the original then the x264 one. So what do you guys think? Is it that x265 is tuned to be less noisy or am I doing something wrong?

LigH how did your tests look? Did x265 retain more grain than x264?

sKRUVEN - interesting results. As we've discussed here, x264 and x265 handle things in very different ways.

As a general rule, when you're trying to evaluate video compression, comparing still frames has very limited value. Still frames show the differences in spatial detail, but you won't be able to see or understand the level of temporal accuracy or noise when you view still frames. You really need to watch the video, side by side, in sync, on the same monitor, or on identical hardware with displays calibrated to match.

For example, to evaluate two 1080P encodes side by side on a 1080P monitor, you could show the left half of one encode side by side with the right half of the other encode. Or you could crop both streams to show only the middle 50% (horizontally), then offset one by 480 pixels to the left, and the other by 480 pixels to the right. If you have a 4K monitor, you can simply composite two 1080P encodes side by side.

The best way for you to do this would be to decode both streams you are comparing to a YUV file, then composite the two decoded YUV files into a single side-by-side YUV file. You could do this in a video editor, cropping and shifting them so that they are side by side, and then exporting as a YUV file. You may also be able to do this with FFMPEG... see http://ianfeather.co.uk/compare-two-webpagetest-videos-using-ffmpeg/ Then, play the composited YUV with YUVplayer or FFPlay. I know this sounds like a big pain, but the result is very revealing.

[raine]

If the source is good quality and sharp the blurring usually is very tolerable and not that noticeable. The problem is much more visible if you have source encoded for example with not the best h264 encoder (pretty much all encoders except x264 including hardware solutions) - now the things that were not very detailed are becoming completely flat.
Also I'm surprised that you get good results at such low resolutions - I would think that x265 would be better than x264 mainly in HD resolution since from what I understand the main improvements are bigger CU and better motion search. Have you tried re-encoding those movies with x264 using good-high settings? Maybe the results would be comparable?

I just tried: with x265 crf=24, the video size was 195MB, using x264 crf=24 -tune film I got 405MB. Both look same as the source (to my eyes). On the bright side, x264 was 8x faster.
BTW, the original video stream is a 1.1GB DX5 stream.

[LigH]

CRF 24 for x264 will probably not mean exactly the same as CRF 24 for x265. But regarding the "level of annoyance" of quality loss, from my experience, it is pretty similar.

[raine]

CRF 24 for x264 will probably not mean exactly the same as CRF 24 for x265. But regarding the "level of annoyance" of quality loss, from my experience, it is pretty similar.

Well, they all look same to me (dx5, x264, x265). I will try to find the highest crf for each at which I can notice distortion.
Edit: I started noticing loss at crf=25 for both. (I should note that I later on tried playing side-by-side with the original video, and slight distortions in some particular frames become apparent event at crf=24 for both. I can't tell them apart @crf=20, but the video size is more than 2x)

[LigH]

If neither looked bad, you can't tell which looked worse. ;)

[fumoffu]

I just tried: with x265 crf=24, the video size was 195MB, using x264 crf=24 -tune film I got 405MB. Both look same as the source (to my eyes). On the bright side, x264 was 8x faster.
BTW, the original video stream is a 1.1GB DX5 stream.

Emm ...are you sure you don't need glasses? :p
Sorry for being smartass but crf24 is rather poor quality especially on lower resolution sources. Could you maybe post some screens here?
Also I was talking about using high = slower settings for x264, something like:
--preset slow --open-gop --bframes 5 --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 0.3:0.15
I know it won't save 200MB but it should help a bit.

[raine]

Emm ...are you sure you don't need glasses? :p
Sorry for being smartass but crf24 is rather poor quality especially on lower resolution sources. Could you maybe post some screens here?
Also I was talking about using high = slower settings for x264, something like:
--preset slow --open-gop --bframes 5 --deblock -1:-1 --subme 10 --trellis 2 --psy-rd 0.3:0.15
I know it won't save 200MB but it should help a bit.
Well, I can't. That particular video is NSFW :D (although maybe I can upload some OK parts, like first few minutes). (Maybe this is the reason for this amount of reduction in filesize since I get around 40-60% for ordinary movies).
However, I can tell them apart when I play the video side-by-side with the original. What I mean is, I can't tell if there is extra loss introduced by x265. At crf=20, I can't tell them apart even side-by-side. Maybe I do need glasses though, but the important parameter for transcoding my archive is whether I notice it or not :)

Quick question, how do I pass these parameters via ffmpeg? Edit: found it: x264opts and replace : with ,

Edit: I sent a PM containing the info on accessing to the first few minutes.

[smegolas]

As a general rule, when you're trying to evaluate video compression, comparing still frames has very limited value. Still frames show the differences in spatial detail, but you won't be able to see or understand the level of temporal accuracy or noise when you view still frames. You really need to watch the video, side by side, in sync, on the same monitor, or on identical hardware with displays calibrated to match.



If a still image shows me that the grain is not retained, it's fair to say the grain has not been retained. It's not going to magically come back in motion.

[benwaggoner]

--tune ssim is on by default
Cool. I didn't notice that change. One more simplification to my command lines :)!

[benwaggoner]

However, I can tell them apart when I play the video side-by-side with the original. What I mean is, I can't tell if there is extra loss introduced by x265. At crf=20, I can't tell them apart even side-by-side. Maybe I do need glasses though, but the important parameter for transcoding my archive is whether I notice it or not :)
So they look the same at CRF 20 and they have equivalent quality but show different minor artifacts when compared at CRF 24.

That makes perfect sense to me. There are multiple routes to "good enough" quality. "Imperceptibly different from the source" and "no visible degradation in encoded stream" are different targets. Something can look a little different from the source but still look great if the viewer isn't comparing it to anything.

And I expect HEVC to have some real advantages here in that its artifacts are going to be less visible. There was an academic paper a while back showing that the viewer preference for HEVC over H.264 was greater than PSNR (and maybe SSIM) would have predicted. The comparison was between the reference encoders, so not directly applicable to x265 v. x264 today. But it certainly gives hope that mature HEVC can have some big relative bitrate savings when targeting "good enough" quality over constrained bandwidths. Also if the degradation is "smoother" we can probably get away with higher frame sizes since the worst frames are less likely to get catastrophically bad.

HEVC is a great next step from H.264, which was the first codec that did a good job of degrading into softness and loss of detail before obvious block patterns started emerging like MPEG-2, MPEG-4 part 2, and to a lesser degree VC-1. Small and variable block sizes plus in-loop deblocking was a very powerful combination.

A key VC-1 developer told me once that the biggest error he wished he could correct was having a mode with a stronger in-loop deblocking filter. VC-1's design was focused more on "minimum bitrate for transparent encoding" and could have done a lot more with "maximum perceptual quality at very low bitrates." Although VC-1 was also designed assuming that the out-of-loop VC-1 postprocessing stage would be used, and would be enhanced over time.

Anyway, HEVC's tuning around deblocking and block sizes seem to really take it to the next stage of lower bitrates just losing detail rather than having a block pattern emerge. Even H.264 High Profile still has trouble with smooth gradients at low bitrates.

[fumoffu]

I saw the NSFW sample video and it's quality isn't the best - a lot of visible compression artifacts already, so it's hard to compare codecs on such video because you are not sure which artifacts were already there and which were introduced during re-encoding. That said x265 can be better at re-encode such videos because it will blur out some of those initial artifiacts while x264 will waste bitrate trying to preserve them ;)

[sKRUVEN]

sKRUVEN - interesting results. As we've discussed here, x264 and x265 handle things in very different ways.

As a general rule, when you're trying to evaluate video compression, comparing still frames has very limited value. Still frames show the differences in spatial detail, but you won't be able to see or understand the level of temporal accuracy or noise when you view still frames. You really need to watch the video, side by side, in sync, on the same monitor, or on identical hardware with displays calibrated to match.

For example, to evaluate two 1080P encodes side by side on a 1080P monitor, you could show the left half of one encode side by side with the right half of the other encode. Or you could crop both streams to show only the middle 50% (horizontally), then offset one by 480 pixels to the left, and the other by 480 pixels to the right. If you have a 4K monitor, you can simply composite two 1080P encodes side by side.

The best way for you to do this would be to decode both streams you are comparing to a YUV file, then composite the two decoded YUV files into a single side-by-side YUV file. You could do this in a video editor, cropping and shifting them so that they are side by side, and then exporting as a YUV file. You may also be able to do this with FFMPEG... see http://ianfeather.co.uk/compare-two-webpagetest-videos-using-ffmpeg/ Then, play the composited YUV with YUVplayer or FFPlay. I know this sounds like a big pain, but the result is very revealing.
I've done some testing now with side by side comparison. And x265 eliminates a lot of grain, to the point were its visible not only in stills but also in side by side comparison (4k cropped to 1080p since i don't have a 4k display). It seems that x265 is optimized for low bitrate, as far as i can tell from this test is that even a bluray-like x264 encodes preserve more film grain then x265. I'm sure this isn't a problem for most sources, but there seems to be a problem with high quality lossless grainy sources. I don't wanna be rude or anything but is it tuned this way on purpose to allow for better efficiency? 50% better efficiency as stated in the press for other encoders isn't that impressive if its denoising the video :P And don't get me wrong, the x265 looks great, it's a lot cleaner and most would probably argue that it looks "better" but it still does a lot of denoising, which is great for low bitrate encodes but maybe not so much for high bitrate ones.

And two other questions: Will a abr encode be exactly the same as a crf encode if they got the same bitrate? And when will there be an option for vbr2pass?

[x265_Project]

If a still image shows me that the grain is not retained, it's fair to say the grain has not been retained. It's not going to magically come back in motion.
True. I didn't say that comparing still frames has no value... just limited value. It makes sense to compare still frames when you are looking for film grain in an area that otherwise has low detail. But for other spatial details you won't be able to easily see if their position is accurate (or whether there is motion judder). You won't be able to see if all of the apparent details should be in the picture or not. For example, temporal noise in H.264 encodes can sometimes produce artifacts that appear as real detail in a still frame, but when you watch the video you'll see that these details are rapidly coming and going, creating nice texture in a still frame, but this high frequency changing texture is perceived as noise when you watch the video.

[x265_Project]

If a still image shows me that the grain is not retained, it's fair to say the grain has not been retained. It's not going to magically come back in motion.

I've done some testing now with side by side comparison. And x265 eliminates a lot of grain, to the point were its visible not only in stills but also in side by side comparison (4k cropped to 1080p since i don't have a 4k display). It seems that x265 is optimized for low bitrate, as far as i can tell from this test is that even a bluray-like x264 encodes preserve more film grain then x265. I'm sure this isn't a problem for most sources, but there seems to be a problem with high quality lossless grainy sources. I don't wanna be rude or anything...
No worries... we have these same discussions all day every day, and we don't mind discussing the issues in public. It's how open source projects move forward.
... but is it tuned this way on purpose to allow for better efficiency? 50% better efficiency as stated in the press for other encoders isn't that impressive if its denoising the video :P And don't get me wrong, the x265 looks great, it's a lot cleaner and most would probably argue that it looks "better" but it still does a lot of denoising, which is great for low bitrate encodes but maybe not so much for high bitrate ones.
No, it's not tuned this way on purpose. You're just seeing one of the differences between HEVC and AVC (H.265 and H.264). We continue to investigate ways to tune our algorithms to optimize these tradeoffs (for example, the tradeoff between more spatial detail and less temporal noise).
And two other questions: Will a abr encode be exactly the same as a crf encode if they got the same bitrate?
No. These are two different rate control modes, and the allocation of bits is going to be different.
And when will there be an option for vbr2pass?
When we have a licensee who funds the development of this feature. We expect this to happen at some point, but the work hasn't been funded yet, and so work hasn't started.

[Dark Shikari]

Retaining grain requires bitrate (though things like psy-RD help). The compression gap between encoders drops dramatically when grain comes into the picture, because it's just random noise and isn't very compressible. x264 might be 4 times better than MPEG-2 on some sources, but you're not going to achieve nearly that kind of gain while retaining grain on a grainy source. It's the same with x265 and x264.

I don't think it's reasonable to expect x265 to ever have similar quality to x264 at half the bitrate when most of the bitrate is spent on incompressible grain.

[sKRUVEN]

No worries....
Thanks for your answers. Gonna murder my cpu some more now, avx2 is fing brutal. And btw, did a crf16 test and yeah it was pretty much transparent, keep up the good work.

I don't think it's reasonable to expect x265 to ever have similar quality to x264 at half the bitrate when most of the bitrate is spent on incompressible grain.
Didn't expect that either :P But it looked subjectively worse at the same bitrate in this case since it took away to much detail for my taste.

[benwaggoner]

Retaining grain requires bitrate (though things like psy-RD help). The compression gap between encoders drops dramatically when grain comes into the picture, because it's just random noise and isn't very compressible. x264 might be 4 times better than MPEG-2 on some sources, but you're not going to achieve nearly that kind of gain while retaining grain on a grainy source. It's the same with x265 and x264.

I don't think it's reasonable to expect x265 to ever have similar quality to x264 at half the bitrate when most of the bitrate is spent on incompressible grain.
If you're trying to replicate the exact same grain pattern per frame in the source, sure. But psychovisual tuning around getting the same general grain texture feel can take advantage of improved codec features. x264 was a big leap forward in that area.

I also imagine that the per-band tuning that HEVC allows could do something nice when tuned to the grain frequencies of a particular source.

[fumoffu]

I don't think it's reasonable to expect x265 to ever have similar quality to x264 at half the bitrate when most of the bitrate is spent on incompressible grain.

Agreed but it would be nice to have some switches to adjust things like that, so you could tune things depending on the source and what you need/want to preserve.

[Procrastinating]

On the subject of test samples, is there any "safe harbor" for test clips of copyrighted material on this site? Screenshots are generally considered okay, so would it be reasonable to share say, 30 second sample footage without sound, or part of the OP of an anime? Where do you draw the line between a sequence of screenshots and an "unsafe" clip, is probably what I am trying to ask.

Generating a greater variety of test samples from "safe" clips of anime say, could be beneficial for tuning and cross-testing a variety of footage.

[smegolas]

True. I didn't say that comparing still frames has no value... just limited value.

Okay, but actually you said very limited value. Which I don't agree with.

[cyberbeing]

On the subject of test samples, is there any "safe harbor" for test clips of copyrighted material on this site? Screenshots are generally considered okay, so would it be reasonable to share say, 30 second sample footage without sound, or part of the OP of an anime? Where do you draw the line between a sequence of screenshots and an "unsafe" clip, is probably what I am trying to ask.

Generating a greater variety of test samples from "safe" clips of anime say, could be beneficial for tuning and cross-testing a variety of footage.

As long as each sample posted exhibits a specific focus or problem, the sample is not larger than required for testing, and you can prove without a doubt that the source of each sample does not violate Rule #6, use good judgment and you shouldn't run into problems.

[benwaggoner]

On the subject of test samples, is there any "safe harbor" for test clips of copyrighted material on this site?

All the Blender titles are Creative Commons licensed, and are great for this kind of use.


Movie-like (available in 4K): http://tearsofsteel.org/
CGI widescreen (available in 4K): http://sintel.org/
CGI 16:9 (now available in 60p 4K 3D!): http://www.bigbuckbunny.org/
CGI 16:9 (now with a stereo 3D version): http://elephantsdream.org/


The top 3 are available as 16-bit per channel image sequences, and so can make great sources for testing 10-bit HEVC.

[LigH]

Neither is a "classical cartoon", though.

[nevcairiel]

As long as the source of the content is legal, short samples fall under Fair-Use, and noone here on the forum will complain, or ever has when a user shared a sample with me. However, Fair-Use doesn't apply if the source of the content violates Rule #6.

[benwaggoner]

Neither is a "classical cartoon", though.
Indeed. Some Creative Commons licensed cel animation or anime would be incredibly valuable.

Why too many "advanced" new codec algorithms fall flat on their faces with that kind of content, as the frequency distribution required is so different.

[Procrastinating]

The big problem is that you really can't go half-way with traditional animation. With CG it's feasible to have a small, dedicated group of volunteers to gradually churn out a project over time, but with traditional animation it's more or less required to form a production committee and pay at least some freelance key animators and the inbetweeners, else the project will never get finished.

One possible route would be to simply ask a studio to release uncompressed footage to the public domain, similar to how studio trigger, at least initially, shared Little Witch Academia.

What lies under "fair use", though? It would be problematic for everyone if we simply uploaded arbitrary sections of footage to only end up debating whether the footage was in fact "fair use". Some house-guidelines like "only 30 seconds of the opening credits" or "a single scene from an episode without sound" would be helpful. The problem with using a catch-all term like "problem cases" is that once the case is no longer a problem case, is it still test footage? Is it still allowed to be shared from that point onward? If a whole five-minute scene is a problem case, can the five-minute scene be shared?

[LigH]

Here is a kind of "Creative Commons Cartoon": Sita sings the Blues (http://www.sitasingstheblues.com/) (downloads at archive.org (https://archive.org/details/Sita_Sings_the_Blues) and from other locations (http://sitasingstheblues.com/wiki/index.php?title=SitaSites)).

Wikipedia mentions earlier Copyright problems (http://en.wikipedia.org/wiki/Sita_Sings_the_Blues#Copyright_problems) before the license was redefined to "CC-0" (public domain).

Unfortunately, an uncompressed version requires a download of 200 GB... A shorter clip would be appreciated.

[smegolas]

All the Blender titles are Creative Commons licensed, and are great for this kind of use.


Movie-like (available in 4K): http://tearsofsteel.org/




Tears of Steel has no grain so while it is representative of modern digitally shot content, in addition you will want some clips to approximate content shot on film.

Some of my favourite Blurays are titles like 3:10 to Yuma or Gladiator and x265 hasn't been outperforming x264 at the kind of bitrates necessary for grain retention.

Sure, if I do something stupid like 1Mbps (for 1080p) then of course it outperforms it but at sensible bitrates or ratefactors x264 starts to retain grain and fine detail very well while x265 still blurs quite a lot.

[Atak_Snajpera]

x265 has still serious problems with cpu utilization

source park_joy_1080p50.y4m

x264 --preset veryslow
http://youtu.be/1dRRo31heTk

x265 (latest from builds.x265.eu) --preset veryslow
http://youtu.be/DU9PD8yl9k0

[kolak]

I have 12 threads at 100% during x265 encodes.

[Atak_Snajpera]

Try with at least 8C / 16T and then we will talk

[easyfab]

And with -F 10 or -F 16 what is the cpu usage and speed

[Atak_Snajpera]

I've just tested with preset medium and cpu usage is surprisingly better 85%-90% but still worse than constant 100% with x264. Playing with --threads value does not help either.

[kolak]

Something is not well threaded in higher preset.

[Atak_Snajpera]

Even default medium is not perfect. Still 10%-15% is wasted (not used) by encoder.

[Procrastinating]

Here is a kind of "Creative Commons Cartoon": Sita sings the Blues (http://www.sitasingstheblues.com/)

Unfortunately even flash animation has its differences from traditional animation, as factors such as auto-tweening, simple backgrounds and sharper edges lead to very different factors in terms of tuning encoders.

Modern anime and cartoons also have important differences such as animating on threes versus twos, different styles of post-processing effects(anime tends to be more in line with cinematic post-processing), different methods of shading and colouring, different methods of in-between weighting and so on.

After searching the internet a little, it seems that there are a few https://en.wikipedia.org/wiki/List_of_animated_films_in_the_public_domain_in_the_United_States Older animated films, as well as some obscure korean films such as "Space Transformers", "Space thunder kids", "Raiders of galaxy" and "defenders of space". Unfortunately most of these sources are likely to be of low quality and/or 240p.

Nowadays it could be feasible to crowdfund a public domain animation project, but that is something which has yet to happen.


One final option would be to straight up buy the rights to some cheap, but contemporary quality and definition, short animated film.

[sneaker_ger]

How does crf scale with internal bit depth at the moment? Some time back crf had to be reduced a lot for 10 bit compared to 8 bit (someone suggested -6 for each extra bit). In a short test with 0.9.91 10 bit crf had to be increased by 8 compared to achieve similar bitrate (maybe related to this commit (https://bitbucket.org/multicoreware/x265/commits/2fb85daef8af16015f876745e8379d2a9f5fbcd6)?). Is this on purpose? Was my test too short? Why the "- 8" in the commit?

[foxyshadis]

HEVC uses the same +6 per bit boost that AVC does, so there should be a 12 quant difference. But it's not perfect since the implementations are slightly different between 8 and 10/16-bit, and crf doesn't perfectly match up to constant quant anyway. If 8 works across a wide range of video types (not just one particular video) then I guess you have your answer.

I wonder if encoding 8-bit video in the 10-bit build differs from encoding it in the 8-bit build?

[zerowalker]

Is there any Comparasions Screenshots available on how it currently compares to x264 in certain bitrates?

[LigH]

Again, and again, and again: Screenshots have only a limited use. Better compare videos, because the temporal development of artefacts of different encoders is different too.

Some screenshots and also videos are published in the VideoHelp forum. I did not try several different CRF values yet, but compared a few CRF 30 encodes of x265 with x264 encodes of the same, double, and triple bitrate (and even quadruple in one case), more details here (http://forum.videohelp.com/threads/360069-x265-HEVC-Encoder?p=2315362&viewfull=1#post2315362). This may be a rather extreme low-bitrate test. Sane bitrates will have much less obvious differences.

[zerowalker]

Yeah i know, i try to keep a pace;P

True indeed, i just want to see screenshots for a simplistic view on how it's going, not any deep technical understanding on how it is.

I like seeing how stuff look one day, and how it has been improved later on, hence why screenshots are simple enough, but of course they never do justice as it's a Video codec and not Image codec.

Actually saw that picture with the people running, that caught my attention as being alot better than i expected, which i somehow doubt, as currently x264 should be ahead of x265 except on some occasion cause of how new x265 is(or perhaps was?).

EDIT:

Tried encoding a video myself, but decoding it seems to cause issues, doesn't Lav Filter support it, or has the Bitstream changed (Latest Version)?

[vivan]

Actually saw that picture with the people running, that caught my attention as being alot better than i expected, which i somehow doubt, as currently x264 should be ahead of x265 except on some occasion cause of how new x265 is(or perhaps was?).If you meant that post (http://forum.doom9.org/showthread.php?p=1677487#post1677487) - then yes, x265 is better at absurdly low bitrates (4 mbps for 4K@50 fps). While x264 simply fails x265 impresses us with amazing quailty (http://i.imgur.com/nyYDFUt.png).

[zerowalker]

Yes that one, it looked truly amazing, something you usually see when one of the encoders settings are completely wrong, and if that isn't the case, i am impressed,
even though x265 is aimed at beating x264, it's spectacular that it can achieve that, doesn't matter if it's low bitrate, that is simply better as the higher bitrate the less the codec matters.

[fumoffu]

...doesn't matter if it's low bitrate, that is simply better as the higher bitrate the less the codec matters.

I don't really agree with this and would like to point out that if your bitrate is limited why not just encode in lower resolution instead?
Both encoding and decoding will be faster so it can be done on slower hardware. But thanks to the laws or marketing it's now common to have HD video encoded with too low bitrate, while even 480p clips encoded with good codec can look good on big screen or at least better than HD video with visible encoding artifacts.
Why artificially inflate video resolutions?

[Asmodian]

even though x265 is aimed at beating x264, it's spectacular that it can achieve that, doesn't matter if it's low bitrate, that is simply better as the higher bitrate the less the codec matters.

You cannot judge relative codec quality at high rates based only on relative qualities at low rates. It is possible to have the low rate look better with this x265 and the higher rate look better with x264.

[zerowalker]

What i simply meant was that the aim for x265 is to reduce bandwidth more, hence why low bitrate efficiency is gold.
By no means am i saying that it's worthless to be efficient at transparent rates, for personal stuff i aim for transparency or similar, but in a global view bitrate is limited and if it can look like 2mbps at 500bitrate, than that is much more worth in that area than transparency bitrates.

Also i don't compare x265 to x264 at higher bitrates, i know that it's only in some scenarios and lower bitrates it currently beats it, but for what it's worth, i think it's great:)