Comparisons of x265 vs x264

[iSunrise]

And they have been doing work on psy, created a grain tuning, changed default aq mode and recently introduced rdoq-level option. To me it is proof they are working on improving quality, it just does not happen overnight nor is it trivial.
I don't disagree, but improving quality also means to rethink some basic code that may have bugs and not just try to overshadow that by adding additional features that might mask the underlying problem.

Answers like the above, meaning "you are the problem" and not giving any details in return is not a good way to deal with people in general. But that's just my opinion.

However, I don't have access to their codebase nor do I ignore the fact that it's free software. Therefore I just wanted to point out what I see in your shots. And since I have some background in programming and predictable AI, what I see at least rings an alarm. After all, you have provided your shots for a reason, didn't you? We are discussing the current state, and I think I made my stance pretty clear in only two posts, but everyone should feel free to disagree (some explanations why would be nice, though).

Let's follow how the state of x265 continues. H.265 will hopefully spawn lots of upcoming implementations to compare, so they really can't ignore thinks like that in the long run.

I wish everyone happy easter holidays!

[benwaggoner]

I don't disagree, but improving quality also means to rethink some basic code that may have bugs and not just try to overshadow that by adding additional features that might mask the underlying problem.
If anyone feels concern about the pace of progress with x265, a quick visit here is always illuminating:

https://bitbucket.org/multicoreware/x265/commits/all

So many commits on so many days, sustained over many many months. Speed improvements, bug fixes, and yes, quality improvements. Remember that --tune grain itself is only about 6 months old. That made for a huge improvement for very noisy content, and with --rdoq-level 1 and other improvements in the last 1-2 months, grain improvement is a whole lot better. For typical film source content @ UHD resolutions, x265 has seen at least a 1/3rd reduction in ABR required for transparent quality versus last summer.

Also, speed improvements ARE quality improvements. If underlying algorithms improve so we can encode with --preset slower at the same speed that we used to get with --preset slow, that gives us better quality in the same encoding time.

Answers like the above, meaning "you are the problem" and not giving any details in return is not a good way to deal with people in general. But that's just my opinion.
I've certainly never heard any blanket feedback like that from them, publicly or privately. Now, they certainly are open that they're focused on video quality when playing back at speed, not at what you see paused and zoomed in on a single frame, so there are "defects" that get reported that aren't necessarily part of their key goals.

However, I don't have access to their codebase
Of course you do. We all do:
https://bitbucket.org/multicoreware/x265/src

...(some explanations why would be nice, though).
That is quite true.

I wish everyone happy easter holidays!
You too. It's really valuable for everyone to keep finding and providing good examples where x265 isn't doing as well as it should. I think the pace of progress should leave us feeling more optimistic, though. I think net improvements are certainly coming faster than in the first 18 months of x264 development!

[Boulder]

I've tried to ask whether it even is possible for x265 to reach the level of x264's details/noise/whatever retention without making it just the same as x264 what comes to compression efficiency, but no answers. That, along with no responses to my two samples, is something that always makes you wonder whether they just ignore you for being critical or actually analyze the issue. I am very keen to help whenever I can but it would be nice to know whether I should redo the same tests every few weeks or not, or is the difference just an accepted fact which is very low on priority.

[Tommy Carrot]

I've certainly never heard any blanket feedback like that from them, publicly or privately. Now, they certainly are open that they're focused on video quality when playing back at speed, not at what you see paused and zoomed in on a single frame, so there are "defects" that get reported that aren't necessarily part of their key goals.
The issue we are talking about, the blurriness compared to x264 at high quality range is not a single frame issue, it's very noticable during playback too. It is also not limited to grain, normal details which are continously there for several frames are noticably less preserved compared to x264. Also, despite the claims that quality is the main priority, i've seen no effort trying to improve this behaviour for several months, which is a bit disappointing because, as you said, the development is otherwise very active.

[benwaggoner]

I've tried to ask whether it even is possible for x265 to reach the level of x264's details/noise/whatever retention without making it just the same as x264 what comes to compression efficiency, but no answers.
It's definitely possible. It's not like there are important tools that H.264 has that HEVC doesn't.

That, along with no responses to my two samples, is something that always makes you wonder whether they just ignore you for being critical or actually analyze the issue.
I've certainly had good results from them with issues I've found. They don't always get fixed right away, but I've always felt taken seriously.

I am very keen to help whenever I can but it would be nice to know whether I should redo the same tests every few weeks or not, or is the difference just an accepted fact which is very low on priority.
I generally keep my eyes on the Commits and retest things when I see a commit has gone in that seems relevant.

I have no doubt that MCW is committed to making it a great encoder for all relevant scenarios, including for what you've demonstrated. Sometimes a fix requires other foundational work that may be in progress. Sometimes there's lower-hanging fruit or higher priorities.

I don't see an issue filed for this on bitbucket. That's been an effective way to get visibility and feedback for a reproducible issue.

https://bitbucket.org/multicoreware/x265/issues?status=new&status=open

[Nevilne]

A good example on why issues like that are not always "just a simple fix", from Daala friends:

https://archive.today/lkABe

[Boulder]

I don't see an issue filed for this on bitbucket. That's been an effective way to get visibility and feedback for a reproducible issue.

https://bitbucket.org/multicoreware/x265/issues?status=new&status=openThanks, that's good to know. I'll file something over the Easter unless someone else does that before I do :)

EDIT: and I definitely understand that fixes or adjustments regarding visual output are usually not simple. Even if x265 is based on x264, the changes under the hood are substantial and it might not be too easy to jump to x264-model psy just like that.

[x265_Project]

This is a very busy time of year in the video business (pre-NAB). I confess that I wasn't keeping up with this thread. x265 isn't just an open-source project - we have many paying customers who we meet with regularly, and we get FAR more feedback than is visible here, and we are working to respond to all of that feedback. While some of our licensees are public, more than half of our paying customers are under NDA; we can't tell you who they are yet. Our customers use x265 in a variety of very demanding environments, from real-time encoding to high quality offline encoding.

As Ben points out, it is possible for x265 to match x264's detail retention. x265 has all of the coding tools of x264, plus many more capabilities found in the H.265 specification (larger block sizes, more accurate prediction, etc.). Quality is job 1, and we continue to focus on every possible way to improve encoding efficiency (visual quality/bit rate). Soon you will see fine-grained AQ, for example. There are many other quality-focused improvements in our development pipeline, but we operate in a competitive market, so it doesn't make sense to tip our hand too early.

Until recently there was a bug in the 1.5 development branch for 2 pass encoding that was causing some loss of fidelity vs earlier builds. The fix was committed just before the 1.6 tag. But I see you were using CRF.

To anyone who thinks building an HEVC encoder is simple, we say; patches are welcomed. The code is available... dive in... these things are simple, right? 19 external contributors have done just that. x265 has over 10,000 commits, with 1.7 million lines of code in those commits. You could be # 20.

[sneaker_ger]

New sample with grainy film. 5000 kbit/s 2pass.

Now extended by increasing x265 bitrate in 1000 kbit/s steps from 5000 kbit/s to 20000 kbit/s.
Download of all output files, scripts and screenshots: https://mega.co.nz/#F!o41EUSCL!JIrixxUhJM093c1Zz1zZLQ

Frame #761 full:
Original:
http://abload.de/img/761_original_rcued.png

x264 5000 kbit/s:
http://abload.de/img/761_05000_x264p2o6x.png

x265 from 5000 to 20000:
http://abload.de/img/761_05000_ybrad.png
http://abload.de/img/761_06000_wlbas.png
http://abload.de/img/761_07000_1ezsw.png
http://abload.de/img/761_08000_h8yht.png
http://abload.de/img/761_09000_71aw3.png
http://abload.de/img/761_10000_huzxu.png
http://abload.de/img/761_11000_asbv3.png
http://abload.de/img/761_12000_pqzfk.png
http://abload.de/img/761_13000_kozfd.png
http://abload.de/img/761_14000_l1yen.png
http://abload.de/img/761_15000_p5bum.png
http://abload.de/img/761_16000_p2b1l.png
http://abload.de/img/761_17000_umyyr.png
http://abload.de/img/761_18000_j2x24.png
http://abload.de/img/761_19000_mzbn0.png
http://abload.de/img/761_20000_7axvu.png


Zoom on the jacket:
Original:
http://abload.de/img/original_jacket_depfb.png

x264 5000 kbit/s:
http://abload.de/img/x264_jacket_crqdk.png

x265 from 5000 to 20000:
http://abload.de/img/x265_jacket_kfrtp.png
http://abload.de/img/jacket_06000_5jjep.png
http://abload.de/img/jacket_07000_ilkpb.png
http://abload.de/img/jacket_08000_wzlne.png
http://abload.de/img/jacket_09000_1pjiv.png
http://abload.de/img/jacket_10000_jdjy1.png
http://abload.de/img/jacket_11000_gzjqd.png
http://abload.de/img/jacket_12000_ztk97.png
http://abload.de/img/jacket_13000_4qjj4.png
http://abload.de/img/jacket_14000_nwkbu.png
http://abload.de/img/jacket_15000_e3k1s.png
http://abload.de/img/jacket_16000_izjkf.png
http://abload.de/img/jacket_17000_54l4r.png
http://abload.de/img/jacket_18000_ynzau.png
http://abload.de/img/jacket_19000_sxkpv.png
http://abload.de/img/jacket_20000_sxkba.png


I wanted to measure noise level but had no idea how to do it. I assumed PSNR and SSIM aren't suited? Ended up using x264 lossless encoding and noted down the bitrates but it didn't seem to be very suitable either. I decided to post the results anyways:
original encoded to x264 lossless preset verfast bitrate in kbit/s:
original: 230565.62

x264 encoded to x264 lossless preset verfast bitrate in kbit/s:
5000: 160547.44

x265 encoded to x264 lossless preset verfast bitrate in kbit/s:
5000: 151798.45
6000: 156417.23
7000: 160516.07
8000: 164185.88
9000: 167596.54
10000: 170695.65
11000: 173436.37
12000: 175990.86
13000: 178269.70
14000: 180476.15
15000: 182604.95
16000: 184780.61
17000: 186720.98
18000: 188712.88
19000: 190538.81
20000: 192498.96

/edit: fixed jacket screenshots 8000, 17000, 18000 + 761_original

[iSunrise]

You too. It's really valuable for everyone to keep finding and providing good examples where x265 isn't doing as well as it should. I think the pace of progress should leave us feeling more optimistic, though. I think net improvements are certainly coming faster than in the first 18 months of x264 development!
Thx benwaggoner.

BTW, do you still happen to have your lagarith "The Island" lossless master somewhere? I tried to access your Skydrive link, but it seems the file has been moved (since MS renamed their service to OneDrive) and is not accessible anymore.

Want to do a few tests on my own, but for tests to make any sense I would love to have access to a real film source that is not pre-compressed.

Would be much appreciated!

[benwaggoner]

Thx benwaggoner.





BTW, do you still happen to have your lagarith "The Island" lossless master somewhere? I tried to access your Skydrive link, but it seems the file has been moved (since MS renamed their service to OneDrive) and is not accessible anymore.





Want to do a few tests on my own, but for tests to make any sense I would love to have access to a real film source that is not pre-compressed.





Would be much appreciated!



I think I've got a Lagarith version around somewhere. I'll try to find it later and pit it somewhere accessible. So nice to not have a 50 MB per file limit anymore!

[Boulder]

Thanks, that's good to know. I'll file something over the Easter unless someone else does that before I do :)OK, here's the report: https://bitbucket.org/multicoreware/x265/issue/122/loss-of-details-compared-to-x264

Now I can say that I've contributed at least something else than empty talk :D

[benwaggoner]

OK, here's the report: https://bitbucket.org/multicoreware/x265/issue/122/loss-of-details-compared-to-x264

Now I can say that I've contributed at least something else than empty talk :D
You've already done a lot more than that :)!

You (and anyone else who's made it this far in this thread) have certainly earned the right to come to my 15th Annual Compressionist Party at NAB on April 14th, if you're at the show.

http://www.evite.com/event/02C7DOTVASHSEA5G2EPE3PFAAV7EHU

[iSunrise]

OK, here's the report: https://bitbucket.org/multicoreware/x265/issue/122/loss-of-details-compared-to-x264

Now I can say that I've contributed at least something else than empty talk :D
Just as a heads-up, I just clicked on your report and wanted to preview the files. It seems that your sample links have accidentally been truncated. You will need to fix this for them to have a look, too. It seems they have already assigned your report, though, looks promising!

Let's wait and see what they have to say about this.

[Boulder]

Dang, you're right. I'll have to comment and add correct links there. Thanks for the heads up :)

[stax76]

I have a question to the testers, how exactly did you make the images? Which tools did you use, could a utility be useful and which features would it need?

[Boulder]

I always load stuff in Virtualdub (decode in script with FFVideoSource), export a snapshot to clipboard, then paste and save in IrfanView. A utility would be nice, maybe load clips to compare and preview a frame to export. I don't know if you can parse the frame type (I, P or B) but that would be very useful too when comparing.

[nikusor665]

Is x265 really that bad at retaining detail/grain ? Does that mean that H265 which will be on the 4k BD will not retain grain ? Cause if its so, than thats a disaster. :scared:

[birdie]

Is x265 really that bad at retaining detail/grain ? Does that mean that H265 which will be on the 4k BD will not retain grain ? Cause if its so, than thats a disaster. :scared:

Currently at low bitrates, yes.

[birdie]

OK, here's the report: https://bitbucket.org/multicoreware/x265/issue/122/loss-of-details-compared-to-x264

Now I can say that I've contributed at least something else than empty talk :D

Most links are broken.

[Boulder]

I fixed those in a separate comment, but for some reason you cannot see the comments unless you are logged into Bitbucket.

[stax76]

I'm building the image grabbing utility into StaxRip now, for every source file opened a tab is created to draw the image on so you can compare directly by switching the tabs, for frame type info it'll rely on a csv file being present which x265 can create, I'll add a checkbox to create it in the x265 dialog, if anybody has special requirements please describe.

I would like to keep it as simple as possible like writing scripts and images in the folder of the source.

What should be drawn on the image? Only the filename?
Is PNG export sufficient and how should the image file names be composed?

Any special AviSynth requirements? So far it generates a very basic script to open the files:

FFVideoSource("test.mkv")
ConvertToRGB(matrix="Rec709")

[stax76]

The utility is finished, it looks like this:

http://s21.postimg.org/71vly217a/Unbenannt.jpg

First test I made with it at 1000 Kbps and 720p, x265 as usual performing poor:

http://s17.postimg.org/q965vh2jx/2116_nv264.png
http://s17.postimg.org/vymefs8q5/2116_nv265.png
http://s17.postimg.org/twlx1jar1/2116_x264.png
http://s17.postimg.org/c7u69wyzx/2116_x265.png

the utility is available here:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

it must be used on top of the last release:

http://sourceforge.net/projects/staxmedia/files/StaxRip%20beta/StaxRip_1.2.2.1_beta.7z/download

[iSunrise]

Wow stax76, that is fantastic work!

I have searched ages for a tool that does exactly that, one that does compare the encoding settings I choose without the need to always have to do manual captures, analyze them in a browser (via tabs) and then re-do the same extremely time-consuming process again and again to look for differences.

What would make the tool perfect:

1) Fast/direct access to the encoder options/parameters (so you can change the values directly) and then real-time viewing (as soon as it got encoded with the new settings) of the result (if I understand this correctly, this may already work, since StaxRip is always running in the background anyway, so is this already possible?)

2) A zoom function for specific image coordinates, which then are identical for all tabs

3) Possibility to have one tab as a reference point (the source) so you can also visually compare the encodes to the source without having to leave your utility

Not only does that allow us to do perfectly valid comparisons, but also to find more problems with specific x265 weaknesses (parameters) and report them to the x265 developers, while we would not have to question whether we did something wrong ourselves or someone messed up somewhere in their workflow when presenting the results here.

If it's possible to include all of the above, too, I will happily donate you something for appreciation of your time spent on this.

I really need to make myself more familiar with StaxRip, you seem really talented.

[Ajvar]

Ligh found that there is new patch b66b0e32d2ff:
Currently adaptive quantization adjusts the QP values on 64x64 pixel CodingTree units (CTUs) across a video frame. The new param option --qg-size will enable QP to be adjusted to individual quantization groups (QGs) of size 64/32/16
Perhaps it is meant to solve these problems?
http://forum.doom9.org/showthread.php?p=1716402#post1716402

[stax76]

1) Fast/direct access to the encoder options/parameters (so you can change the values directly) and then real-time viewing (as soon as it got encoded with the new settings) of the result (if I understand this correctly, this may already work, since StaxRip is always running in the background anyway, so is this already possible?)

In StaxRip you would reload the project at: main menu > Project > Recent and encode it again without changing the target file name, what's missing is a reload feature in the comparison utility, this should be fairly easy to add.

Also possible would be a option that the utility would always load and reload all files in a given directory, should also be fairly easy to add.

2) A zoom function for specific image coordinates, which then are identical for all tabs

This could be difficult, most simple approach would be performing zooming and cropping with AviSynth letting the user script this but I don't know how the workflow and implementation could exactly look like.

3) Possibility to have one tab as a reference point (the source) so you can also visually compare the encodes to the source without having to leave your utility

You can already open any file.

If it's possible to include all of the above, too, I will happily donate you something for appreciation of your time spent on this.

So far it's 3 hours work and 200 lines (not counting the form designer) so no problem, I'm looking forward using it often, with the Intel H265 encoder and a new vpxenc GUI for VP9 coming soon there will be enough opportunity for comparisons.

[Ajvar]

I personally use AVSviewer for such job. Open 2 windows with 2 different files (actually launching 2 Hybrids, adding files and clicking Avisynth preview on both), select Info checkbox (frame info) and just Alt+Tab this stuff. But thanks for doing this anyway, that is cool feature for those who use StaxRip and it's more comfortable as it looks.

[stax76]

Where can I download AVSviewer?

[stax76]

My codec comparison tool is now more complete and mature.

http://oi57.tinypic.com/aaad01.jpg

A pre-release can be found here:

https://www.dropbox.com/sh/xiyz10pghli8pvf/AAB3k0Dg-TRF-vh6srbITYDBa?dl=0

It must be used with the latest StaxRip release 1.2.2.1:

http://sourceforge.net/projects/staxmedia/files/StaxRip%20beta/StaxRip_1.2.2.1_beta.7z/download

It can be found in the main menu under Tools/Advanced/Codec Comparison.

I'm looking for sample clips that are great for codec comparisons so if somebody has some link to share that would be awesome.

[Ajvar]

Where can I download AVSviewer?

Emm, I use the one which came with Hybrid. Like this.
Here is the folder with it (https://mega.co.nz/#!lVokiTiC!wDTcsmQNJJM6BbwU-NpixXShlaE8CEzjS-2aWGcZC74). You can ask Selur where does he take or if it's his own.
And here is screenshot.
http://i.imgur.com/FjKqzmI.png
I think that your addon can be really great if you could use one Key for switching from one pic to another (Left-Right arrows or some one-key) and maybe possibility to create key-combo with KEY - Sequence of image to switch (like switch between 1, 3, 5) by user.

[Nic]

For those that want to test grain retention with x265, could you try the build up at:
http://nic.pe.hu
and use "-preset nic" (plus whatever rate control you want to use, like --bitrate 7000, etc)

Let me know if that's any better, will put up the source and explanation tomorrow (it's bed time :) )

Cheers,
-Nic

[sneaker_ger]

If anyone wants to see an encode made with the patch:
https://mega.co.nz/#!ZwFxGRAC!TlFr5ES87TQA90ok3pwrCkCKCovmnmPwxPZHbXTuN1Q

[Nic]

@sneaker_ger: This is v2 of the mod, so might be better than your tests with v1. Thanks so much for the help!

[benwaggoner]

For those that want to test grain retention with x265, could you try the build up at:
http://nic.pe.hu
and use "-preset nic" (plus whatever rate control you want to use, like --bitrate 7000, etc)

Let me know if that's any better, will put up the source and explanation tomorrow (it's bed time :) )

Cheers,
-Nic
What does the patch change?

[dapperdan]

A Google team working on WebRTC is trying to create an open source toolchain for objective codec comparisons, they have x264 and x265 included currently:

http://compare-codecs.appspot.com/results/show_result.html?codec1=x264&codec2=x265&criterion=psnr

It's not quite ready for launch as far as I can tell (there's some obvious bugs in the results and TODO's in the text) but I think the idea is very cool and potentially useful. (There's similar stuff going on at Daala's https://arewecompressedyet.com/?x265&x264).

The whole idea is to encourage contributions, so I thought some people here might have the knowledge necessary to make the tool better:

http://compare-codecs.appspot.com/contributing/

https://github.com/google/compare-codecs

(a slight tangent, Ben Waggoner mentions earlier about progress of codecs over time. I notice in github they have code for MJPEG and
H.261 and H.263 but those results aren't currently displayed on the website).

[MasterNobody]

A Google team working on WebRTC is trying to create an open source toolchain for objective codec comparisons, they have x264 and x265 included currently:

http://compare-codecs.appspot.com/results/show_result.html?codec1=x264&codec2=x265&criterion=psnr

It's not quite ready for launch as far as I can tell (there's some obvious bugs in the results and TODO's in the text) but I think the idea is very cool and potentially useful. (There's similar stuff going on at Daala's https://arewecompressedyet.com/?x265&x264).

The whole idea is to encourage contributions, so I thought some people here might have the knowledge necessary to make the tool better:

http://compare-codecs.appspot.com/contributing/

https://github.com/google/compare-codecs

PSNR only codec comparison in 2015? Is it a joke?

[MoSal]

PSNR only codec comparison in 2015? Is it a joke?

No. It's marketing.
Compare x265 with vp9 and you will get the idea.

The team working on Daala is the only one not actively trying to insult our intelligence nowadays, it seems.

[dapperdan]

I believe they have plans to implement all the objective metrics from the Daala arewecompressedyet.com site (PSNR, SSIM, FastSSIM, PSNR-HVS) and any others that have freely available code to calculate them. I meant to mention that specifically as I thought that might distract from the potential of a shared, repeatable toolchain for objective comparisons, but thought it fell under the general heading of "obvious bugs and TODOs".

Rather than a cycle of people doing half-hearted, one-off comparisons where they don't fully describe their process, or give you access to their inputs, or do any number of silly things that might invalidate the whole process, here's a chance for people to work together to fix the problems, and share the benefits of automating the boring bits while also exploring whatever codecs, tools, test sets, or objective metrics particularly interest them.

If the idea was to bamboozle people with carefully staged benchmarks to favour Google's own codecs, then this level of transparency wouldn't be a particularly smart move on their part.

[iSunrise]

My codec comparison tool is now more complete and mature.
I've had some time today to test your codec comparison tool and it's really really great for such an early build. It's extremely easy to search and compare certain scenes between different encodes.

Some bugs and suggestions to improve it as follows:

1) Open dialog (after clicking on "Add files to compare") by default only shows *.mkv, *.webm and *.mp4. Can you please add *.m4v and *.png, too?

2) A jump to position/time index xx:xx:xx.xxx would be helpful. The mouse cursor is great for fast searching on scenes throughout the files, but very bad when you want to jump to a specific position/time index instantly.

3) It would be helpful if you could re-order your tabs by clicking a tab and move your mouse left or right while holding the left mouse button.

4) It would be great if you could close a tab by right-clicking it and select "close selected tab". This is currently only accessible when clicking in the actual view window, but not when directly clicking a tab.

5) If you close the very last tab the codec comparison tool throws an exception. This should be easy to fix.

Need more time to test it more thoroughly. Now on to some actual x265 testing.

[stax76]

@iSunrise

I've copied your post to my todo list.

[stax76]

@iSunrise

All five suggestions and some more improvements are in the latest beta.

http://forum.doom9.org/showthread.php?p=1717543#post1717543

[Ajvar]

@iSunrise

All five suggestions and some more improvements are in the latest beta.

http://forum.doom9.org/showthread.php?p=1717543#post1717543

Wow! Just tried it at it's really nice tool! Is it possible to add additional mouse keys work as next 100 frames Next/Previous?

[iSunrise]

@iSunrise

All five suggestions and some more improvements are in the latest beta.

http://forum.doom9.org/showthread.php?p=1717543#post1717543
Great! Did some comparisons today, astounded by it's usefulness.

One thing though, you seem to have added *.m4a in the open file dialog instead of *.m4v, probably a typing mistake.

[stax76]

Wow! Just tried it at it's really nice tool! Is it possible to add additional mouse keys work as next 100 frames Next/Previous?

Just added it.

One thing though, you seem to have added *.m4a in the open file dialog instead of *.m4v, probably a typing mistake.

Thanks, I also changed it to use LSMASHVideoSource for MP4/M4V.

[iSunrise]

Thanks, I also changed it to use LSMASHVideoSource for MP4/M4V.
Great, where can I download and test? Last available is 1.2.2.2-beta.

I think I've got a Lagarith version around somewhere. I'll try to find it later and pit it somewhere accessible. So nice to not have a 50 MB per file limit anymore!
Ben, did you have time to upload it somewhere, yet? Would really appreciate it!

[stax76]

l-smash don't load hevc 10-bit so I reverted to ffms2, what I improved in the tool is avs and ffindex files are saved in the system temp dir and cleaned up after usage. The built is here:

http://forum.doom9.org/showthread.php?p=1719130#post1719130

It's based on AviSynth+ 64-Bit as described in the first post of the thread.

[sneaker_ger]

l-smash don't load hevc 10-bit
It does, you're doing something wrong. See readme about format and stacked parameters.

Can you maybe open a new thread for your tool to keep this one clean?

[stax76]

You mean I need to pass a argument? We can discuss it in the StaxRip thread.

[Ajvar]

Just added it.

I would love to try it but for 2 latest days I tried 4 times to download Alphas from dropbox and never got past 15MB for 1.3.0.1 and 30+MB for 1.3.0.0.
Not a big surprise... Microshaft. Never did anything good since Windows 7.

[zambelli]

Just tested x265 v1.7+374 and noticed that the detail loss issue is still present. x264 @ CRF18 looks sharper than x265 @ CRF15, despite an almost identical file size. Has any progress been made in solving this problem?