x265 HEVC Encoder

[x265_Project]

I was answering to the posts about the grain modeling, not talking about periodic intra refresh.
Ahh... my mistake.

[Sagittaire]

Bug Report

x265 v. 1.849 report intra refresh problem in multipass mode between first and second pass. But I don't touch intra-refresh setting between first and second pass.


x265.exe --input hp.yuv --output crf23.265 --input-res 720x304 --fps 25 --bitrate 450 --qcomp 0.75 --pass 1 --stats hp.log --preset veryslow --aq-mode 0 --aq-strength 0.0 --psy-rd 0 --rdoq-level 0 --psy-rdoq 0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim

x265.exe --input hp.yuv --output crf23.265 --input-res 720x304 --fps 25 --bitrate 450 --qcomp 0.75 --pass 3 --stats hp.log --preset veryslow --aq-mode 0 --aq-strength 0.0 --psy-rd 0 --rdoq-level 0 --psy-rdoq 0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim

[Ma]

x265 v. 1.849 report intra refresh problem in multipass mode between first and second pass.

Reported: https://bitbucket.org/multicoreware/x265/commits/1bcfea4372d90ceca3db6c262eaaf191#comment-2434983

If you can't wait for patch, find "intra_refresh" in source/encoder/ratecontrol.cpp and replace with "intra-refresh".

[jlpsvk]

How is improvement in 8bit color gradients encoding? are there any fixes already in v1.8?

[~ VEGETA ~]

How is improvement in 8bit color gradients encoding? are there any fixes already in v1.8?

you mean encoding without having banding? I have interest in that too. H.264 10-bit does GREAT job in that, but I need to know if HEVC 10-12 bit can do similar job with less size.

BTW, anyone knows if 12 bit gives smaller size that 10 bit? any page that explains this?

[LigH]

I believe the developers already explained that 12-bit encoding is rather meant for encoding of higher original component precision (like medical images), it may not have much more advantage over "10-bit compared to 8-bit depth" for common video sources (means, you may recognize a difference between 8 and 10 bit easily, but between 10 and 12 bit hardly). And it may require more bitrate. 10 bit encodes being more efficient than 8 bit in many cases is rather lucky, but you should not extrapolate: The more diverse values an entropy encoder (like Huffman or Arithmetic Coding) has to process, the worse the compression usually gets.

[~ VEGETA ~]

I believe the developers already explained that 12-bit encoding is rather meant for encoding of higher original component precision (like medical images), it may not have much more advantage over "10-bit compared to 8-bit depth" for common video sources (means, you may recognize a difference between 8 and 10 bit easily, but between 10 and 12 bit hardly). And it may require more bitrate. 10 bit encodes being more efficient than 8 bit in many cases is rather lucky, but you should not extrapolate: The more diverse values an entropy encoder (like Huffman or Arithmetic Coding) has to process, the worse the compression usually gets.

well, 12 bit requires more bitrate than 10 bit? I didn't think it is like this because 8 vs 10 was different. Do you have some reliable source?

I don't care about how much difference would exist between 10 and 12 as long as it is better (12)... as I don't care about encoding speed and stuff like that.

[LigH]

I said "it may", not "it does always". It will probably depend a lot on the material; 10 bit depth encoding more efficiently than 8 bit will probably not always be true either, I mainly know such reports from cartoon content. In theory, quantizing to at most 1024 instead of 256 different values (ignoring the limits of "TV range") should be harder to compress because there can be 4 times as many different values to compress. And with 12 bit, there are 4096 different values per component, so once again 4 times the amount. So why should it get even smaller in general?

But "smaller size at the same quality" is nonsense anyway. You can't measure absolute quality. Quality is relative (always compared to another sample) and subjective (depends on the viewer). Size is objective. You can measure file size. You can try to make three videos with almost the same size as good as it gets, then compare which has the best quality in your personal opinion. And you can ask hundreds of people to do the same, and gather statistics how many of them preferred which clip.

By the way, how many tests did you make on your own before asking?

[jlpsvk]

yeah...i meant banding...

[LigH]

Banding is often a result of quantization limits reducing the accuracy of the bitdepths of color components even further. A higher bitdepth increases the accuracy first, but the quantization needs to reduce it even more then to reduce the diversity of values for the entropy encoding ... tl;dr: maths – getting more accurate first gives a little better chance to not loose as much accuracy later, so increasing the bitdepth from 8 to 10 bit is useful to avoid banding. But that may be enough ... increasing further to 12 bit may not support accuracy noticably anymore, just worsen the compressibility, I guess. To be tested with a lot of different material ...

[~ VEGETA ~]

But "smaller size at the same quality" is nonsense anyway

Perhaps you didn't get me right. I meant using the exact same settings like --crf 17 --aq-mode 3 ....etc, using 8-bit and 10-bit. Here, 10-bit gives less file size with better quality, especially with the banding and some details. Perhaps "same quality" is a bad word choice.

As you know, 10 bit allow more accuracy (more values) than 8 bit (color values...), so when you say use Dither to filter the stupid banding, it gives lots of values that you must store! using the same crf, 8 bit has less values than 10 bit which will allow 10 bit to give a better result always. If you want the same quality with 8 bit, you must lower the crf, which will give a bigger file size always. Tl;DR: you can conserve details and get good quality in 10-bit without lowering CRF. In 8 bit, you must. Which gives a smaller size in 10bit.

BTW, file size is subjective too. One may find 400mb too small and someone else find it a lot. So, by the same concept, you can not say "my encode gives small size". However, nowadays people can tolerate 400-600mb per episeode (720p-BD-10bit), so it is not really important.

By the way, how many tests did you make on your own before asking?

Many... but with x264. I didn't use x265 yet as I can not now... that is why I am asking. What got my interest is the 10 vs 12 bit in terms of quality and file size, which I did not get satisfying answer to it yet.

[LigH]

Well, so you did never read the warnings about CRF: "never compare results with the same CRF but different options otherwise" ... "--crf 17 -D 10" may cause a similar size as "--crf 17 -D 8", or not, who knows. The development of the relation between rate factor and size with different CRF values is probably different for 8 bit depth and 10 bit, imagine curves with a different slope: You can't find one scale factor that will make match both for more than a small range.

And no, file size is objective. Two files of the same size have the same size on any PC. Independent of the content. What is subjective about videos with a specific size, is if this size is enough for a satisfying quality. Of course, different movies have a different demand of bitrate to provide "enough quality to be satisfied".

[foxyshadis]

Anyone can easily see 8-bit banding on even a terrible monitor. It takes a high-end studio monitor and well-trained eyes to spot banding on 10-bit, so visible quality will not increase by moving to 12-bit. Further, the raw efficiency increase due to better matches for increasing the bit-depth is logarithmic; the increase from 6 to 8 bits would be enormous, from 8 to 10 bits slightly noticeable, from 10 to 12 bits minuscule, and lost in the noise. And that's for relatively clean sources. With enough bits, the increase always eventually stalls and goes backwards, as there's more detail/noise in the low bits to attempt to record in most sources.

12-bit is designed more for archival, so that more bits can be put to good use to preserve little shadow and color detail for later re-grading, that would otherwise be lost. That's what high-depth jpeg2000 and motion-jpeg2000 are already used for.

I gave it a couple of tests, but unlike 10-bit, I see no reason to ever move to it unless I'm archiving my own personal projects.

[xxxxx]

How is improvement in 8bit color gradients encoding? are there any fixes already in v1.8?

I did a few test recently, unfortunatelly there is no impovment at all. The new aq-mode 3 just add more bitrate the dark areas wich can help a very little but overall i had the same terrible banding as always. Also, can't see any significant improvment in detail preserve. This 2 issue exists from the beginning, seems developers just ignore them.
I'll check again a year later...

[LigH]

... seems developers just ignore them.

Such insults may be a reason to stop public testing... :angry:

Don't demand miracles for free. Be grateful for the development progress already shared with you. And don't complain that they prefer to develop first the tasks they get paid for...

The developers already stated that they would return to investigating detail loss further when they completed 12-bit encoding and related tasks requested by their commercial partners.

[~ VEGETA ~]

Well, I am convinced that quality gained from 12 bit is very little compared to 10 bit. However, if someone has a powerful encoding machine and doesn't give a damn about encoding/releasing time (like me), it is always good to encode in 12 bit. Especially that moderate devices these days (core i3) runs 1080p-12bit-HEVC very nicely.

I guess this is what you meant by archiving, except that it will be a real release.. because some people are too old for weekly fansubbing &___&, thus they release once/month or something very lazy.


If you tried enough, will encoding in 12 bit be less size than 10 bit while having the exact same settings and source (and everything)?

[MeteorRain]

If you tried enough, will encoding in 12 bit be less size than 10 bit while having the exact same settings and source (and everything)?

12 bit, by the number itself, will cost 20% more bitrate than 10 bit. After that, you start stripping the information encoded to reduce the bitrate back to the same level as 10 bit. So it's hard to say 12 bit will always be more efficient than 10 bit, but we'll see.

And, for the same QP (I'm not saying CRF because it's a flexible concept), 12 bit will be bigger than 10 bit. (And the same applies to 8 bit vs 10 bit.)

[Sagittaire]

12 bit, by the number itself, will cost 20% more bitrate than 10 bit. After that, you start stripping the information encoded to reduce the bitrate back to the same level as 10 bit. So it's hard to say 12 bit will always be more efficient than 10 bit, but we'll see.

And, for the same QP (I'm not saying CRF because it's a flexible concept), 12 bit will be bigger than 10 bit. (And the same applies to 8 bit vs 10 bit.)


Well, old Ateme plublication show that 10 bits will be higher efficiency in most case than 8 bits encoding for H264 (better efficiency is higher metric at same size here).

Anayway like Ligh say, comparison must be to do always at the same size . It's not subjective condition. It's really easy to make encoding at same crf or quantizer with really different size (use different quantizer matrix for exemple). Crf and quantizer doesn't mean anything for quality. crf at 17 with all coef at 255 in quantizer matrix will produce less quality than crf at 30 with all coef at 4.

[nevcairiel]

Well, old Ateme plublication show that 10 bits will be higher efficiency in most case than 8 bits encoding for H264 (better efficiency is higher metric at same size here).

The main reason why this was so efficient for H264 does not apply to HEVC anymore though, so the gains should be smaller, and moving from 8 to 10 will still have considerably more benefit than going from 10 to 12 (for native 8-bit content).

On top of that, there is the argument that many decoders may not be very well optimized for 12-bit decoding. But then, since when did Anime folks care about that, huh.
Personally I would stay away from 12-bit, unless your source is that high bitdepth already.

[~ VEGETA ~]

Well, old Ateme plublication show that 10 bits will be higher efficiency in most case than 8 bits encoding for H264 (better efficiency is higher metric at same size here).

Anayway like Ligh say, comparison must be to do always at the same size . It's not subjective condition. It's really easy to make encoding at same crf or quantizer with really different size (use different quantizer matrix for exemple). Crf and quantizer doesn't mean anything for quality. crf at 17 with all coef at 255 in quantizer matrix will produce less quality than crf at 30 with all coef at 4.

By using the same source and settings we can see the difference, and it is a good comparison. I don't use per-defined bitrate, only CRF.

Comparing 2 encodes using the same settings is always a good choice if not the best. The reason 10-bit gives smaller size than 8-bit... is that it has more values (allows more values to be stored...) and thus better quality. However, if 8 bit wants to achieve the same quality it will necessarily need more bitrate because it has less values.

This theory applies to 10 vs 12 too, regardless of the real visible difference. If my post has mistakes, please show them to me.

[LigH]

The reason 10-bit gives smaller size than 8-bit... is that it has more values (allows more values to be stored...) and thus better quality. However, if 8 bit wants to achieve the same quality it will necessarily need more bitrate because it has less values.

Well, now this is illogical. Did you ever try to understand "entropy encoding" using the works of Claude Shannon, Robert Fano and David A. Huffman? ... Maybe too complex for someone not graduated in Computer Science; let's have a look at the Morse code table, even though it is not binary but has even four different states (short and long signal, short and long break).

Which letters have the shortest Morse codes? The most commonly used letters in English language: E and T. The more less commonly used letters you take into account, the longer their codes get. And when even numbers and specific telegraphy states where added, they already required 5 elements.

I hope it gets obvious that the more different entities have to be encoded, the longer the required code words get, the harder the data is compressible. The exception for 8 vs. 10 bit depth is that both get quantized before compression. Quantization means losing precision, losing quality.

Imagine, the compression is done on 7 bit precision in both cases to achieve a similar size after encoding; then the 8 bit encode loses 1 bit, the 10 bit encode loses 3 bit. So why may it still give better quality? ... Because calculating YUV values out of RGB samples in only 8 bit already lost some precision, it did a kind of "quantization before quantization". And this was done regardless of the available bitrate, regardless of frequency components after the transformation from samples to visual frequency spectrums per (macro-) block.

Converting 8 bit RGB values to YUV values with only 8 bit precision was "content independent quantization". Reduction of psychovisually relevant frequency components is content dependent quantization, thus more subjectively satisfying. Converting 8 bit RGB to 12 bit YUV would not give you much more useful precision for a later quantization of frequency components, compared to 10 bit YUV values, because both will lose a considerable amount of precision (and both will lose more precision than the already rather coarse 8 bit results) when their frequency component values will be quantized later.

[Sagittaire]

By using the same source and settings we can see the difference, and it is a good comparison. I don't use per-defined bitrate, only CRF.

Comparing 2 encodes using the same settings is always a good choice if not the best. The reason 10-bit gives smaller size than 8-bit... is that it has more values (allows more values to be stored...) and thus better quality. However, if 8 bit wants to achieve the same quality it will necessarily need more bitrate because it has less values.

This theory applies to 10 vs 12 too, regardless of the real visible difference. If my post has mistakes, please show them to me.

No simply that like you say, 8 bits and 10 bits are not same setting by definition. If you want make comparison, you must use same bitrate. Crf and quantizer are not absolute quality level.

Anyway if your conclusion is "10 bits produce more quality and less bitrate than 8 bits at same crf", certainely that advantage for 10 bits will be higher at same size. Make comparison at same crf (and different bitrate) don't show the real difference (negative or positive here).

[gonzales3]

Hello to everybody. My question is about Tenth MSU Video Codecs Comparison. How it is possible that in ripping mode two different results are present. From what I've read the parameters of compression were both the same for "Destkop" and "Server" configuration.

http://114.imagebam.com/download/9A-jxmQQ4LfijoLHc0eiGg/44301/443009367/msu1.png

http://113.imagebam.com/download/cqCVlhsRLowUcHz7V6wfaA/44301/443009371/msu2.png

[littlepox]

Hello to everybody. My question is about Tenth MSU Video Codecs Comparison. How it is possible that in ripping mode two different results are present. From what I've read the parameters of compression were both the same for "Destkop" and "Server" configuration.



The reason is that multi-threading in video encoding sometimes have to be coupled with efficiency sacrifice.

For example, x264 uses --threads which is set to 1.5 * No. of logic cores BY DEFAULT. The more threads it is allowed to use, the less efficient the coding shall be.

Most of the time you won't spot any noticeable difference if it is <=18, e.g, your CPU has no more than 12 logic cores. But for the "server" they use, which is equipped with E5 2697v3(14C28T), the threads for x264 will be set to 28*1.5=42. The difference will at least be demonstrable by objective benchmark.

Luckily HEVC got some optimize on multi-threading with little or no pain, for example, the WPP feature. So it is as expected to see that for server settings, x265 enjoys a slight advantage comparably.

[mandarinka]

WPP does have some "pain", actually. AFAIK it has even been stated in this thread that while it should be under 1% hit or so, it is probably higher impact than just using frame threading as x264 does.

[~ VEGETA ~]

@LigH: isn't entrocopy encoding meant for lossless? can you explain why 10-bit gives better quality and less bitrate consumption? I already explained why in my point of view.

I admit, you are more technically aware than me in this thing. I tried to say the stuff you just said about quantization but didn't succeed obviously. I still think my explanation is correct, as it is tried numerous times. Having 2 bits more yet smaller size and better quality is not normal or expected given the 2 additional bits. However, I talked about visible quality of 2 encodes (8 and 10), 10 gives smaller size for that quality than 8 bit. If 8 bit wants to give the same quality, it needs more bitrate and thus bigger size.

you mentioned quantization and quantization before quantization... this is where 10 bit excels, where it has more accurate processing than 8 bit, but storing bitstream is done in 8 bit (I guess, not very sure). Decoder converts it back to 10 later on.

@Sagittaire

Hmmm yes that was my conclusion after testing stuff back when H.264 10-bit appeared (others has the same too). My whole point was like you put in quotation marks... 10 bit gives better quality and less size at the same CRF. I still think using the same x264 settings and the same CRF is fair method for comparison. Of course, comparing at the same bitrate is valid too.

[~ VEGETA ~]

Entropy coding itself is 100% lossless. And the entropy coding stage is where the encoder actually "saves" bits. Simply put, the idea is that we use few bits to code the likely "symbols" (input values), and many bits to code the unlikely "symbols" (input values). However, the data that enters the entropy coding stage must be "suitable" for entropy coding, if you want to achieve a noteworthy bit saving. For example, applying an entropy coder on "random" data (where every input symbol may appear with equal probability, regardless of what symbols we have seen before) would not save any bits at all! So, everything that happens before entropy coding, such as quantization, serves one goal: Make the data more "adequate" for entropy coding, and thus save more bits in the entropy coding stage. It's the quantization stage (not the entropy coding stage) that makes the whole process lossy. Still, they are closely related.

nice explanation, is there good tutorials or texts to read in this subject?

[LoRd_MuldeR]

@LigH: isn't entrocopy encoding meant for lossless? can you explain why 10-bit gives better quality and less bitrate consumption? I already explained why in my point of view.

Entropy coding itself is 100% lossless. And the entropy coding stage is where the encoder actually "saves" bits. Simply put, the idea is that we use few bits to code the likely "symbols" (input values), and many bits to code the unlikely "symbols" (input values). However, the data that enters the entropy coding stage must be "suitable" for entropy coding, if you want to achieve a noteworthy bit saving. For example, applying an entropy coder on "random" data (where every input symbol may appear with equal probability, regardless of what symbols we have seen before) would not save any bits at all! So, everything that happens before entropy coding, such as quantization, serves one goal: Make the data more "adequate" for entropy coding, and thus save more bits in the entropy coding stage. It's the quantization stage (not the entropy coding stage) that makes the whole process lossy. Still, these two stages are closely related.

Now, whether the input value has a precision of 8-Bit, 10-Bit or 12-Bit is pretty much unrelated to how many bits we need to spend to store it in the encoded bitstream, i.e. after entropy coding stage! If a certain symbol/value is very likely to appear, then the entropy coder may be able to encode this particular symbol/value with a single bit - or even less than a single bit (which is actually possible with arithmetic coding). At the same time, symbols/values that are very unlikely to appear may require a large number of bits to encode. Whether the symbol is an 8-Bit, 10-Bit or 12-Bit number - or something completely different - doesn't matter here. For the entropy coder, the input value is just some symbol out of a certain alphabet.

[LoRd_MuldeR]

nice explanation, is there good tutorials or texts to read in this subject?

For entropy coding, I suggest you start with Huffman coding:
https://en.wikipedia.org/wiki/Huffman_coding

Also I suggest that you read the Wikipedia article on JPEG to get an idea how lossy compression works:
https://en.wikipedia.org/wiki/JPEG#Encoding

Yes, JPEG is only about still images, but many fundamental concepts are pretty much the same for video encoding. Especially the "transformation → quantization → entropy coding" data flow!

[LigH]

A few additions:

JPEG and MPEG-1/2 Video use a 2D "Discrete Cosine Transform" to calculate frequency spectrum parameters from pixel / color component values; this is a finite variant of the Fourier series. AVC and HEVC will prefer a partially different transform function, but with the same purpose: To describe rather the structure of a color ramp across a square / rectangle of few pixels than each pixel on its own. A blurry, little structured area needs only a few parameters of low frequency parts of the 2D spectrum to be encoded with sufficient precision. If there is video content with only little motion or even static content, then the difference between two frames will have very little structure, so P and B frames hardly need to store any relevant differential frequency parameters in such still parts.

[foxyshadis]

We're getting way off from a discussion of x265 itself, though. The biggest gain from 8->10 bit is visually; the efficiency is minimal (<1%), especially in HEVC. AVC gains more, but still only a little. Any efficiency gain from 10->12 would be 1/4 whatever the first transition will be at most, the overhead of extra bits might even reduce that some. There is no visual gain since I know you can't see a difference between 10 and 12-bit YUV even without dithering.

You can spend your sweet time encoding to that, at more than twice the time, and completely eliminate the possibility of ever playing it back on anything but a PC software decoder, or just stick with the main10 that was designed specifically for everyone who wants much better than 8-bit but full hardware compatibility. Moving to a higher bit-depth is not something do to lightly, or because you have some feelings about it, but because you need it.

The only reason I'd ever go off-main for anything but archival would be to use the screen-coding rext tools, which x265 doesn't have.

[Jamaika]

Does anyone know when will be added High profile with the codec X265?

[foxyshadis]

HEVC high tier just means a higher bitrate, and x265 can support any bitrate. What are you looking for? There are many profiles, but HEVC doesn't have a high profile the way AVC did.

[LigH]

There is no "High profile" in the HEVC specification. See: Wikipedia: High Efficiency Video Coding – Profiles (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles) (v2 introduced many specific profiles, still most of them are named based on "Main").

[Jamaika]

HEVC high tier just means a higher bitrate, and x265 can support any bitrate. What are you looking for? There are many profiles, but HEVC doesn't have a high profile the way AVC did.
There is no "High profile" in the HEVC specification. See: Wikipedia: High Efficiency Video Coding – Profiles (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles) (v2 introduced many specific profiles, still most of them are named based on "Main").
Umh..., well, I understand that my suggest is nonsense. However, I don't know what to think about exceptions.
https://www.sendspace.com/filegroup/olhPsjIRXQFwcsxSO3JkCQ

[vivan]

That file is main profile high tier. And x265 supports that (https://x265.readthedocs.org/en/default/cli.html#cmdoption--high-tier).

[Jamaika]

OK, http://i60.tinypic.com/jzctxk.jpg
The funktion --high-tier for me doesn't work for X265 and displays communique:
x265 [info]: Main profile, Level-5 (Main tier)
I don't know how to use it. :(

[vivan]

It works fine here http://i.imgur.com/XduTssT.png
Did you even read what I linked? It says If --level-idc has not been specified, this argument is ignored.

In the description manual PowerDirector doesn't have the word "tier".Use MediaInfo.

[Jamaika]

If --level-idc has not been specified, this argument is ignored.
Let me ask ex. --level-idc 4.1 and what's next? What must other functions be switched on?

Edit: I already know.
x265 [info]: Rate Control / qCompress : ABR-20000 kbps / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 45000 / 20000 / 0.900

[LigH]

Weekly with a few bug fixes

x265 1.8+60-6563218ce342 (GCC 4.9.2) (https://www.mediafire.com/download/dp8nbc881q055og/x265_1.8+60-6563218ce342.GCC492.7z)
x265 1.8+60-6563218ce342 (GCC 5.2.0) (https://www.mediafire.com/download/a8y52fjyjae83po/x265_1.8+60-6563218ce342.GCC520.7z)

[~ VEGETA ~]

Weekly with a few bug fixes

x265 1.8+60-6563218ce342 (GCC 4.9.2) (https://www.mediafire.com/download/dp8nbc881q055og/x265_1.8+60-6563218ce342.GCC492.7z)
x265 1.8+60-6563218ce342 (GCC 5.2.0) (https://www.mediafire.com/download/a8y52fjyjae83po/x265_1.8+60-6563218ce342.GCC520.7z)

where to download compiled versions of the encoder? plus, is there any mods right now like tmod or something? especially those who has aq-mode 3.

:D

[LigH]

:scared: What do you think is inside these 7-zip archives? — Yes, binaries! :o

And why mods? The "vanilla" builds already contain "--aq-mode 3". And to use x265 with other video sources than YUV or Y4M files, there are already many solutions (VirtualDub 1.10+ external encoder; avs4x26x; StaxRip; MeGUI; Hybrid; ...). The x265 developers still have tight focus on encoder core features, the time for convenience additions has not yet come.

[stax76]

they could probably add AviSynth and VapourSynth support in no time, it should only be a matter of copy and paste little code from other open source encoders like QSVEncC, many users and tool makers would be thankful.

[~ VEGETA ~]

:scared: What do you think is inside these 7-zip archives? — Yes, binaries! :o



Duh I know! it is very obvious. I asked about a certain site that automatically compile and upload new versions (like some x264 ones) rather than looking in a forum post to see one post out of hundreds that has a downloadable binaries. :(

[Ma]

I asked about a certain site that automatically compile and upload new versions

The list of sites with x265 binaries:
http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds

For CPU with SSE4.2 or better quite fast are VS 2015 builds:
www.msystem.waw.pl/x265/

[Jamaika]

Does the site https://encoder.pw/ has been blocked?

[LigH]

Blocked where against what? It requires a rather strong HTTPS cipher, but with a recent browser I can access it (Opera 12 is obsolete here). Most should have TLS 1.x enabled and SSL 3 disabled already.

[cengizhan]

Blocked where against what? It requires a rather strong HTTPS cipher, but with a recent browser I can access it (Opera 12 is obsolete here).

sec_error_revoked_certificate with firefox 41

[LigH]

Well, that's another issue. It seems that Mozilla either does not trust the Certificate Authority (COMODO RSA Domain Validation Secure Server CA) anymore which granted the certificate of this website, or the certificate to this server has been revoked by the CA. In this case, probably the latter.

You might disable the use of the Online Certificate Status Protocol (OCSP) in the advanced security options of Firefox, but this is usually enabled for a good reason. So you may have to wait until the maintainer of this website will buy another certificate (if he agrees to pay that money).

Qualys SSL Labs analysis (https://www.ssllabs.com/ssltest/analyze.html?d=encoder.pw)

[foxyshadis]

Someone must have stolen the private key or hijacked the server. Ouch. Good idea to wait until the situation is cleared up.