x265 HEVC Encoder

[yup]

Hi all!
I am testing x265 for my VHS capture archive and I can speak that x265 save half space without quality degradation if comparing to x264.
I am deinterlace source (720x576i 25) and upscale to 960x720p 50, picture not sharp.
May be exist special approach for choose some setting?
yup.

[LigH]

@ froggy1 + plane:

In other words:

a) There is an algorithm to encode B frames in general. This implementation appears to be technically correct.

b) There is an algorithm to decide when to use a B frame in the video stream. This implementation appears to be improvable, more or less subjectively.

Am I correct here?
__

@ yup:

VHS is not sharp anyway. And upscaling it further... depends already on the deinterlacing / bobbing filter you used. Possibly QTGMC? You may combine that with an EDI algorithm (upscaling with edge directed interpolation, usually by powers of 2 as factor, then downscaling to the desired final resolution with usual resizers).

But this is not a matching question in this thread, because it is not related to details of the x265 encoder. This topic fits better in the "AviSynth usage" subforum.

[yup]

[QUOTE=
@ yup:

VHS is not sharp anyway. And upscaling it further... depends already on the deinterlacing / bobbing filter you used. Possibly QTGMC? You may combine that with an EDI algorithm (upscaling with edge directed interpolation, usually by powers of 2 as factor, then downscaling to the desired final resolution with usual resizers).

But this is not a matching question in this thread, because it is not related to details of the x265 encoder. This topic fits better in the "AviSynth usage" subforum.[/QUOTE]

Ligh! Small misunderstanding!
I am interesting for X265 setting for encoding my source (not script writing), because one have some specific. Now I am using preset only and increase quntity B frames up to 10, because footage is lecture with static background.
May be some advice?
yup.

[Barough]

x265-v2.0+16-215eedc9ecc0 (http://www102.zippyshare.com/v/Ac0Mki24/file.html) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

[microchip8]

@LigH

yes, you are correct. it's also the reason why b-adapt=1 was recently improved in latest x264. There's nothing to improve in the b-frames implementation as it's decently done. b-adapt (especially, b-adapt=1) was suboptimal and that's what the devs improved recently. So you can't blame b-frames being "not mature" while in fact you're talking about the decision x264 uses when to use them

[JohnLai]

@LigH

yes, you are correct. it's also the reason why b-adapt=1 was recently improved in latest x264. There's nothing to improve in the b-frames implementation as it's decently done. b-adapt (especially, b-adapt=1) was suboptimal and that's what the devs improved recently. So you can't blame b-frames being "not mature" while in fact you're talking about the decision x264 uses when to use them

Which is why I asked if x265 already adapted the newer b-adapt=1 code.....b-adapt=2 is too slow at determining 16 bframes placement although it is better.

[LigH]

x265 2.0+16-215eedc9ecc0 (GCC 5.3.0) (https://www.mediafire.com/download/lk6kgl89b353duw/x265_2.0+16-215eedc9ecc0.GCC530.7z)
x265 2.0+16-215eedc9ecc0 (GCC 6.1.0) (https://www.mediafire.com/download/27oehkyfh7d51lk/x265_2.0+16-215eedc9ecc0.GCC610.7z)

New CLI options:

--qpmin <integer> sets a hard lower limit on QP allowed to ratecontrol. Default 0
--qpmax <integer> sets a hard upper limit on QP allowed to ratecontrol. Default 69
...
--log2-max-poc-lsb <integer> Maximum of the picture order count
--[no-]sei-dump Emit SEI packets in bitstream. Default enabled

[x265_Project]

x265 2.0+16-215eedc9ecc0 (GCC 5.3.0) (https://www.mediafire.com/download/lk6kgl89b353duw/x265_2.0+16-215eedc9ecc0.GCC530.7z)
x265 2.0+16-215eedc9ecc0 (GCC 6.1.0) (https://www.mediafire.com/download/27oehkyfh7d51lk/x265_2.0+16-215eedc9ecc0.GCC610.7z)

New CLI options:

--qpmin <integer> sets a hard lower limit on QP allowed to ratecontrol. Default 0
--qpmax <integer> sets a hard upper limit on QP allowed to ratecontrol. Default 69
...
--log2-max-poc-lsb <integer> Maximum of the picture order count
--[no-]sei-dump Emit SEI packets in bitstream. Default enabled
We're going to change the syntax of --sei-dump to --discard-sei. This option enables encodes that create SEI messages, consider their size as part of the bit rate (as usual), but discard them instead of writing them to the bitstream. This allows a user to encode an identical bitstream as they would have when SEI messages were included, but without SEI. It's not something most users would ever need.

[x265_Project]

IBM has contributed a set of files containing POWER optimizations. Although this is not in proper patch format, I'm guessing that any competent developer familiar with IBM POWER 8 servers can build and run the optimized version of x265. The x265 team will review, test and commit these improvements as soon as possible, but it may take some time as we've got every developer and then some spoken for right now. So any test or code review feedback from the community of x265 developers would be welcomed. Thanks to IBM for contributing to x265!

Files were uploaded to https://bitbucket.org/multicoreware/x265/downloads

Tom

[Selur]

what's the min/max for log2-max-poc-lsb ?

[x265_Project]

FYI - Netflix has posted on their Tech Blog, notifying people about a large study they have completed comparing x264, x265 and VP9 (libvpx). The results will be published Wednesday morning Pacific time.
http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html


We ran a large-scale comparison of x264, x265 and libvpx to see for ourselves whether this 50% bandwidth improvement is applicable to our use case. Most codec comparisons in the past focused on evaluating what can be achieved by the bitstream syntax (using the reference software), applied settings that do not fully reflect our encoding scenario, or only covered a limited set of videos. Our goal was to assess what can be achieved by encoding with practical codecs that can be deployed to a production pipeline, on the Netflix catalog of movies and TV shows, with encoding parameters that are useful to a streaming service. We sampled 5000 12-second clips from our catalog, covering a wide range of genres and signal characteristics. With 3 codecs, 2 configurations, 3 resolutions (480p, 720p and 1080p) and 8 quality levels per configuration-resolution pair, we generated more than 200 million encoded frames. We applied six quality metrics - PSNR, PSNRMSE, SSIM, MS-SSIM, VIF and VMAF - resulting in more than half a million bitrate-quality curves. This encoding work required significant compute capacity. However, our cloud-based encoding infrastructure, which leverages unused Netflix-reserved AWS web servers dynamically, enabled us to complete the experiments in just a few weeks.

What did we learn?
Here’s a snapshot: x265 and libvpx demonstrate superior compression performance compared to x264, with bitrate savings reaching up to 50% especially at the higher resolutions. x265 outperforms libvpx for almost all resolutions and quality metrics, but the performance gap narrows (or even reverses) at 1080p.

Want to know more?
We will present our methodology and results this coming Wednesday, August 31, 8:00 am PDT at the SPIE Applications of Digital Image Processing conference, Session 7: Royalty-free Video. We will stream the whole session live on Periscope and YouTube: follow Anne for notifications or come back to this page for links to the live streams. This session will feature other interesting technical work from leaders in the field of Royalty-Free Video. We will also follow-up with a more detailed tech blog post and extend the results to include 4K encodes.

[Motenai Yoda]

It is something like Thursday night at 22/23/24 in Europe

- I'm a full thrust idiot it is Wednesday night not Thursday

[Atak_Snajpera]

We applied six quality metrics - PSNR, PSNRMSE, SSIM, MS-SSIM, VIF and VMAF - resulting in more than half a million bitrate-quality curves.
Looks like another useless codec comparision. As We know codec with lower PSNR,SSIM or something can actually look better for our eyes/brain. x264 with enabled psy is a good example.

[x265_Project]

Looks like another useless codec comparision. As We know codec with lower PSNR, SSIM or something can actually look better for our eyes/brain. x264 with enabled psy is a good example.
The research team at Netflix know what they're doing. They understand that subjective quality is more important than objective quality measurements. But subjective testing is very time consuming and expensive, and it wouldn't be feasible to cover a wide range of content at a wide range of bit rates and picture sizes (pixel resolutions). Netflix has also been researching better objective quality metrics, with the goal of correlating more closely to subjective visual quality measurements.

[smok3]

What could applying
8 quality levels per configuration-resolution pair
mean?

[x265_Project]

We sampled 5000 12-second clips from our catalog, covering a wide range of genres and signal characteristics. With 3 codecs, 2 configurations, 3 resolutions (480p, 720p and 1080p) and 8 quality levels per configuration-resolution pair, we generated more than 200 million encoded frames.

3 Codecs - x264, x265, and VP9
2 Configurations - I'm assuming that a "configuration" means a rate control mode (CRF, or 2 pass ABR), or a performance preset. But we'll see.
8 quality levels - CRF value or target bit rate. You need multiple quality levels in order to generate a rate-distortion curve. You need a rate-distortion curve in order to compare codec efficiency.


5000 clips x 12 seconds x 24 frames/sec x 3 codecs x 2 configurations x 3 resolutions x 8 quality levels = 207,360,000 frames.

[LigH]

:scared: Better you have a "render park" available...

[x265_Project]

:scared: Better you have a "render park" available...
As they explained, they do...
However, our cloud-based encoding infrastructure (http://techblog.netflix.com/2015/12/high-quality-video-encoding-at-scale.html), which leverages unused Netflix-reserved AWS web servers dynamically (http://techblog.netflix.com/2015/09/creating-your-own-ec2-spot-market.html), enabled us to complete the experiments in just a few weeks.

[littlepox]

Looks like another useless codec comparision. As We know codec with lower PSNR,SSIM or something can actually look better for our eyes/brain. x264 with enabled psy is a good example.

The sad part is that people loves numbers and graphs.
Whatever reasonably looking numbers are true and reliable
Whoever publish them are professional and fair.

If I'd claim, according to my own eyes to compare visual quality, x265 saves 30% bitrate to x264 while libvpx only saves 10%, those crappy hevc/vp9 encoders perform even worse than x264. Who's going to trust me?

On this basis, then you have to acknowledge, although far from perfect, SSIM remains one of the most powerful indicators for visual quality, and PSNR for distortion measure.

[Motenai Yoda]

Looks like another useless codec comparision. As We know codec with lower PSNR,SSIM or something can actually look better for our eyes/brain. x264 with enabled psy is a good example.

Yep but when a codec has better PSNR and SSIM is a good hint, and if it's the same on a large number of clips and with many better metrics like PSNRMSE, MS-SSIM, VIF and the newest VMAF too is a big hint.
also on comparing high quality/bitrate encodes metrics are more realiable than on mid/low quality ones.

also in many mid/low bitrate cases vp9 overtake x265 by a bit

inversely to what I said months ago on VP9, x265 looks me to try to preserve too much fine detail (new psy-rd and rdoq defaults?), I proposed about an year ago to dynamically decrease aq and psys at high quantizers (indeed at very low and very high ones)

[x265_Project]

Today I'm publishing a proposal to accelerate HEVC adoption. I look forward to a productive conversation.
http://x265.org/proposal-accelerate-hevc-adoption/

[tebugg]

Today I'm publishing a proposal to accelerate HEVC adoption. I look forward to a productive conversation.
http://x265.org/proposal-accelerate-hevc-adoption/

"Proposal To accelerate HEVC adoption, I propose that HEVC patent licensors agree to the following principles;

All HEVC patent holders should make their patents available through a patent pool
Ideally, all patent holders should join one patent pool
Only one reasonable royalty should be paid per device
Software decoding on consumer devices must be royalty free
Software encoding on consumer devices must be royalty free
Content distribution must be royalty free
There must be a reasonable cap on total royalties owed for HEVC implementations"


would this also mean that any improvements that have not made it to the open source x265 due to patent limitations would then be pushed to the open source and would benefit people like us that use x265 for personal use?

[x265_Project]

...would this also mean that any improvements that have not made it to the open source x265 due to patent limitations would then be pushed to the open source and would benefit people like us that use x265 for personal use?
There is no part of the HEVC standard that hasn't made it to x265 due to patent limitations. We license x265 to commercial companies without patent coverage (we explicitly require licensees to identify obtain all necessary patents). Of course, if HEVC patents are too expensive or difficult to license, it hurts our commercial business, and that isn't good for open source adopters, as we won't be able to continue to grow our development team and invest in x265.

[x265_Project]

Netflix presented the results of their large-scale study, comparing x265 to x264 and VP9 (libvpx)...
https://www.youtube.com/watch?v=wi1BefrfTos&feature=youtu.be&t=1h25s

Naturally, if you don't use --tune ssim, results are worse when measured using SSIM. When they avoided --tune psnr and --tune ssim their own visual quality metric showed that x265 delivered the best visual quality. Similarly, when tuned for objective metrics, x265 is the clear winner when measured with objective metrics.

[mariush]

I also noticed that they used 8 bit content (they had higher bit content but they brought it down to 8 bit before passing to encoders) and they used the 8bit encoders - i would have loved to see 10 bit x264 encodings compared to the others.
Also, they didn't mention anything about using -tune animation or something like that when encoding cartoons / anime / whatever with x26* (they said they did apply psycho visual tunings but didn't say in detail what)

Another thing they did was they used preset placebo but I suspect they wouldn't use this in production because 1080p content encoded with placebo may not play on older video cards or some hardware boxes/devices ... it would make sense to lower some parameters at the very least, to get something that's not quite placebo.

[x265_Project]

Another thing they did was they used preset placebo but I suspect they wouldn't use this in production because 1080p content encoded with placebo may not play on older video cards or some hardware boxes/devices ...
Why do you say that?

[Jamaika]

Interesting test. Actually, it is to eliminate the codec libvpx. Who can tell me what means "Visual quality tuned"?
Are these codec parameters resulting from setting a placebo?

[x265_Project]

Interesting test. Actually, it is to eliminate the codec libvpx. Who can tell me what means "Visual quality tuned"?
Are these codec parameters resulting from setting a placebo?

It means they didn't use --tune psnr or --tune ssim, or turn off psy-rd or psy-rdoq. If you watch the presentation, you'll see the explanation.

Also check out my explanation here... http://forum.doom9.org/showthread.php?p=1779649#post1779649

And check out http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=113346

[NikosD]

The AVX2 optimizations of x265 have started to play a role.

On the same clip I benchmarked a Sandybridge and a Haswell system using x265 v2.0+5 with the default medium preset without changing any switch.

Core i5-2400 5,94 fps
Core i7-4790 13,09 fps

The Haswell system has faster base clock, faster DDR3 RAM, faster turbo clock, hyperthreading and larger L3 cache.

Clock for clock with the same L3 cache, turbo, RAM speed and hyperthreading, Haswell is not yet twice as fast but is has a significant advantage.

[JohnLai]

The AVX2 optimizations of x265 have started to play a role.

On the same clip I benchmarked a Sandybridge and a Haswell system using x265 v2.0+5 with the default medium preset without changing any switch.

Core i5-2400 5,94 fps
Core i7-4790 13,09 fps

The Haswell system has faster base clock, faster DDR3 RAM, faster turbo clock, hyperthreading and larger L3 cache.

Clock for clock with the same L3 cache, turbo, RAM speed and hyperthreading, Haswell is not yet twice as fast but is has a significant advantage.

Now that explain why I3-4330 3.5ghz encoding speed is almost similar to overclocked 4.2Ghz I5-3570k....

[GigaWatt]

Hi. I'm new to this forum, but I've been following doom9's threads and posts for years. I've been playing around with encoding video and I've found most of my answers in some thread on doom9, but for a few months now, I've been having a problem that I haven't been able to solve by myself.

I've been using x265 as my primary encoder for about a year now with MeGUI and Simple x264/x265 Launcher as frontends. My interests are aimed towards lower bitrates (to about 1000, maybe a little more)... basically, I'm interested in lowering the bitrate as much as possible (in combination with some filters and tuning, mostly grain) and tuning the psychovisual enhancements to achieve maximum subjective quality of the encode. The resolution of the encoded videos is 720p (8 bit sources and encodes). For indexing, I'm using L-SMASH (2 pass encodes). So, basically, I do everything in MeGUI except the encode, which is done in Simple x264/x265 Launcher.

OK, now, let's get to the actual problem. It seems that the --tune grain command in the newer versions of x265 doesn't seem to be working as well as the older ones... at least subjectively. For example, the older versions (to about 1.9+3, that's the last one that was bundled with Simple x264/x265 Launcher and worked "correctly") blured the video at lower bitrates, thus subjectively giving the audience the perception that "this is just how the video was shot/edited". Newer versions (1.9+3 and above) don't seem to do this quite as good as the previous versions, i.e. the video is just more pixelated (not blured).

At first, I thought that it might be a problem with MeGUI or/and Simple x264/x265 Launcher (I'm using the development update server of MeGUI), but apparently, this is not the case.

I haven't done a changelog analysis of x265 (mostly because it's time consuming, something that I don't have much of lately), but I did see some new commands being added in the 2.0 versions of x265 (have no idea if they where there after 1.9+3 and before 2.0x). For example, there is a new CLI command in the analysis chain, --[no-]rskip, which I though might be the culprit so I disabled it (added --no-rskip to CLI). It didn't give me the result I was hoping for. The encode was slightly better, but... not as blured as with the 1.9+3 version. So I tried another approach. Even though --rc-grain is enabled when encoding with --tune grain, I tried adding it in the CLI, just in case. Subjectively, this had no effect on the end result, which probably means that the --tune grain parameter is working correctly and enabling --rc-grain. So, I tried adding --no-slow-firstpass (apparently, --slow-firstpass is enabled by default after 1.9+3), which I thought might "dumb down" the analysis during the first pass and (hopefully) blur the encode. Again, subjectively, there was some improvement, but, not what I was hoping for. So, I tried adding all three commands as custom CLI parameters... as I thought, it didn't help me get the result I was hoping for.

So, my question is, what has changed in the --tune grain parameter since 1.9+3 and how do I get back to doing the encodes the way I want to (blurry, not pixelated).

[LigH]

Welcome.

A lot has changed in the "grain" tuning, partially quite deep inside the encoder. Because it was supposed to preserve the grain, not to remove it. You may find all the details in the x265 commit log, but they will be very technical... Best anchor would probably be to analyze the set of basic parameters this complex tuning consists of.

3e53004 (https://bitbucket.org/multicoreware/x265/commits/3e530043698b9df0f9aba7eefbb381ac6cc79421): grain: improve grain handling settings / Turn off SAO, increase psychovisual settings to better retain high frequency

305a127 (https://bitbucket.org/multicoreware/x265/commits/305a1272a412e6da50544c151820631b319de1cc): rc: fix Rate Control for grainy content / optimize params for tune grain, reduce frequent qp fluctions to prevent grain loss

(Probably a few more...)

To return to the old blurring behaviour, you will certainly not use "--tune grain" anymore. But what instead ... may be too much for me to be able to summarize that. Most probably you would keep SAO enabled, I remember that this feature was most frowned upon by those who preferred to preserve the grain.

[GigaWatt]

Thanks for the welcome ;). Glad to "officially" be a part of doom9's forum ;).

Well, the "--tune grain" parameter was the only thing actually gave "good" (blurry) results for me. I didn't mention this before, but I was using it even if the video didn't contain any grain (subjectively) just so that I could get a better psychovisual experience of the video at lower bitrates.

I would say that this is something to think about... adding a new tune parameter in x265? Perhaps "--tune blur" or something similar? I know it's a lot to ask for at this stage of the development (have no idea if that is even in conformance with the HEVC standards), but not everyone is after better quality and preserving grain (although, yes, I have to admit that that would be the goal of any development, making something better, not worse). I think that many web developers will also find a feature like this very handy in online content (save bandwidth and storage, get the same user experience... psychovisually ;)).

Anyhow, here is what x265 2.0+2 "long help" says about SAO:

Loop filters (deblock and SAO):
--[no-]deblock Enable Deblocking Loop Filter, optionally specify tC:Beta offsets Default enabled
--[no-]sao Enable Sample Adaptive Offset. Default enabled
--[no-]sao-non-deblock Use non-deblocked pixels, else right/bottom boundary areas skipped. Default disabled

Basically, it says that it's enabled. Does "--tune grain" disable SAO or has no effect on SAO (stays enabled)? Or, as you suggested, I don't use any tune parameters, just enable all loop filters (--deblock --sao --sao-non-deblock)?

Best anchor would probably be to analyze the set of basic parameters this complex tuning consists of.

I was afraid I'd get that answer :S. I was hoping to avoid that, but hey, on the plus side, I'll probably learn a lot ;).

Thanks for your help ;).

[divxmaster]

I've been getting great results firstly using
QTGMC filter and then smdegrain filter. This does however require a knowledge of avisynth/vapoursynth,
with vapoursynth being much more preferable. I taught myself vapoursynth from scratch/google so perhaps
you can also?

used on 576p, so far ds9, sg1, voyager, the results are incredible. bit rates are 400-600 range. it is super sharp
though when seen up close, but is great at a normal viewing distance.

Note that QTGMC does enhance the picture, even if its not interlaced, in some situations.
I see you use 8bit encodes. If you can, try and use 10 bit. More and more hardware now has 10 bit decode,
including the new kaby lake processor.
You don't need SAO if you use the above filters, and in fact it blurs the picture quite a bit.

Cheers,
Divxmaster

[GigaWatt]

I also didn't mention in my first post that I'm familiar with AviSynth scripts and I usually edit the scripts in the end (after being generated with MeGUI). I have't tried VapourSynth at all, but from what I've read, it seems like it's next logical step, so I will try to get into it soon.

I also had great results with MosquitoNR (32, 0 settings), so I used it in combination with "--tune grain" in x265. I haven't tried QTGMC and smdegrain though, but will, thanks for the suggestion ;). Also, I was afraid of encoding at anything larger than 8-bit, mostly because of the lack of hardware (and, in some cases, also software) support, but I haven't been in pace with the changes in this area, so I wasn't aware that things are not what they used to be in this area. Again, thanks for the input and will try a 10-bit encode ;).

One problem though. You're encoding at 576p at 400-600. I was getting good results at 700-1000 at 720p with "--tune grain" and MosquitoNR. I dind't have to use --tune grain and MosquitoNR at 900-1000, but with any bitrate below, say... 800 or 850, I used both of them. It also depended on the source. If there was not a lot of movement in the scenes of the video and if the source required black bar cropping (end resolution = 1280 x 534, 536...), the end result would be great even at 700 without "--tune grain" or MosquitoNR. As I said, it depends on the source.

Anyhow, I will try to do an encode with no tune parameters (SAO disabled) and the filters you suggested ;). Will post with subjective results :D.

[x265_Project]

Pradeep gave an update on x265 at VideoLan Developer Days...
https://www.youtube.com/watch?v=oT8HueAQZ4w

[K.i.N.G]

Are there any (official) multilib binaries?
I can only find seperate (official) builds for 8, 10 & 12 bit?

[LoRd_MuldeR]

Are there any (official) multilib binaries?
I can only find seperate (official) builds for 8, 10 & 12 bit?

Not "official", but anyway:
https://forum.doom9.org/showthread.php?p=1778529#post1778529

[LigH]

I keep posting irregularly, here and in the VideoHelp forum. Here is an archive on MediaFire (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC), all 7-zip files contain 32-bit and 64-bit builds both as 3-in-1 multilib EXE and as separate EXE and DLL files per bitdepth. It is not "official", just plain, compiled from the Mercurial source repository by GCC in an MSYS/MinGW environment, no additional patches.

[x265_Project]

Help us share the good news on Slashdot! Old school techies deserve to know. Vote for this story here... https://slashdot.org/submission/6278679/netflix-finds-x265-20-more-efficient-than-vp9

Edit: We made the front page of Slashdot! Thanks for your help.

[Gravitator]

@x265_Project
Asking you to encode my sample with their highest settings at a bitrate of 6800kbit/s (2-pass desirable).

https://mega.nz/#!dFdjlL5Q!X-39N69mg22VEH-eX9tvnDBHGmKVyEDgAX6o74k2G78

[dipje]

I'm going to guess you're going to get a 'you can do it yourself' reply.

[Leo 69]

@Gravitator

Since I saw you were trying Selur's Hybrid, that's a nice tool to make a HEVC encode at the highest setting.
In the encoding settings of x265 select preset "Placebo", 2-pass, 6800 kbps. That should meet your needs.

[K.i.N.G]

Not "official", but anyway:
https://forum.doom9.org/showthread.php?p=1778529#post1778529
I keep posting irregularly, here and in the VideoHelp forum. Here is an archive on MediaFire (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC), all 7-zip files contain 32-bit and 64-bit builds both as 3-in-1 multilib EXE and as separate EXE and DLL files per bitdepth. It is not "official", just plain, compiled from the Mercurial source repository by GCC in an MSYS/MinGW environment, no additional patches.

Thanks LoRd_MuldeR & LigH!!!
:thanks:

[microchip8]

@ dipje @ Leo 69

I think he wants the x265 people to test their encoder with his sample, as it may be problematic

[Jamaika]

CRF isn't a linear function of the bitrate.
One film ex. CRF=24 4K 23.976fps time will bitrate 700kbps, for another of the same framerate and frame size is 6000kbps. It depends on the dynamics of the film.

[filler56789]

x265.exe build 2.0+51 is out.

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2458958&viewfull=1#post2458958

[Barough]

x265-v2.0+54-e5ca9b210223 (http://www71.zippyshare.com/v/MXhVqx8x/file.html) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

[RainyDog]

x265-v2.0+54-e5ca9b210223 (http://www116.zippyshare.com/v/nO2B2mnq/file.html) (MSYS/MinGW, GCC 6.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

Thanks for the new build again Barough.

[LigH]

A question came up in the mailing list about the implementation of tiles. According to the Wikipedia, HEVC supports different parallel processing tools (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Parallel_processing_tools), x265 implemented WPP (Wavefront Parallel Processing) first, but is just implementing slices as well (imaginable as horizontal stripes of possibly different heights, IIRC), and tiles would even allow to split video frames into a grid of rectangular sub-frames.

I hope someone has the knowledge and the time to compare these tools a bit more in depth. I believe they have important differences in parallelizability and encoding efficiency (also regarding possible quality limits due to a restricted scope).