x265 HEVC Encoder [Archive] - Page 64

divxmaster

21st January 2016, 20:58

As per my post #3123, one page back, I am getting great results with vapoursynth 'vid = haf.SMDegrain(vid, tr=3,thSAD=400,RefineMotion=True,contrasharp=True,pel=2)'
for degraining.
thSAD 400 for heavy grain, 250 for medium and 150 for light grain.
I have tested -nr-intra and -nr-inter a lot, and found it blurs way too much, even on nr 100. I only use it for encodes for mobile devices, at 400, since the screen is so small.
I will have to check out KNLMeansOpenCL also.

Cheers,
Divxmaster

foxyshadis

22nd January 2016, 00:32

KNLMeansCL, no Open in the name. It's nearly as good as SMDegrain at 10-100x the speed, since it runs on GPU and thus runs faster the better your graphics card. It's far better to use AVS or VS to remove your grain, they're actually dedicated to fixing video, whereas x265 only has one knob that incidentally sometimes works OK. Alternately, you can use ffmpeg to do both filtering and encoding on one command-line, although its filtering isn't quite as high quality.

LigH

22nd January 2016, 09:13

As far as I understood the --nr-* options, they don't reduce the noise; they rather try to store it in a simplified way, to maintain its amount while reducing its complexity which makes it hard to encode. It's rather a "noise remodeling" than a "noise reduction". Correct me if I'm wrong...

If you want to reduce noise, pre-filtering the source is indeed recommendable. An encoder has to assume that the video it receives is just as you want to see it when its encoding result is decoded again.

burfadel

22nd January 2016, 10:13

As far as I understood the --nr-* options, they don't reduce the noise; they rather try to store it in a simplified way, to maintain its amount while reducing its complexity which makes it hard to encode. It's rather a "noise remodeling" than a "noise reduction".

I don't believe that is the case, it's just a very mild noise reducer. Typically I've found around 400-450 for both options allows you to use a slightly lower quality factor (meaning higher quality) without affecting picture detail. Basically, I believe the bitrate saved that can go towards a lower quality factor (meaning higher quality) maybe from say, 22 to 21 for example.

divxmaster

23rd January 2016, 22:02

I don't believe that is the case, it's just a very mild noise reducer. Typically I've found around 400-450 for both options allows you to use a slightly lower quality factor (meaning higher quality) without affecting picture detail. Basically, I believe the bitrate saved that can go towards a lower quality factor (meaning higher quality) maybe from say, 22 to 21 for example.

I initially thought that, but then I used video comparison in staxrip and it showed there was a lot more blur than I thought, when I was just comparing videos side by side. Just checking you have used video comparison or similar on it? I find with crf20, smdegrain makes the file 30% smaller on heavy grain video, so the size is great. This is for Full HD only.
I cannot get video comparison to open the .m2ts at the correct size, so I run a --lossless sample to compare to.

Cheers,
Divxmaster

nandaku2

24th January 2016, 06:19

Hi guys,
I have a grainy video and I wanna encode it to x265 but it's killing me.
I tried --nr-inter --nr-intra at first. but it's not quite what I have in mind. it removes some noises not all, and in same scene with still camera and everything, remaining noises come and go. I mean it's not practical at all.
I also tried --tune grain. It made the video so blur. Almost removed all the noises but the problem is keyframes. like when the camera changes, all the noises appear for little amount of time and then they disappear. it's so annoying and again, not practical at all.

any suggestion?

Hello,

We completely agree with you that tune grain in its present form is not acceptable. Can you please try this patch out? (https://patches.videolan.org/patch/12030/). This changes the behaviour of tune grain, and though the whole feature isnt ready as a user option just yet, I think you'll find the results much better and the grain more consistent. Would be great to hear about some initial test results.

sneaker_ger

24th January 2016, 07:58

param->rc.cuTree = 0;
:eek:

Sagittaire

24th January 2016, 16:41

param->rc.cuTree = 0;
:eek:

No suprise. cuTree use RD curve (if my memory is good) and will certainely use higher quantizer in high textured part of the image. (Noise is by definition high textured area)

Moreover, Noise is by definition in all screen part, and use cuTree is not really usefull here.

To preserve noise, you must generaly reduce temporal and spacial quantizer variation: this patch make that with low ipfactor, ibfactor, high qCompress and desactive all AQ option. It's really not big surprise.

sneaker_ger

24th January 2016, 18:06

That's all nice and well but x264 seems to do fine without the sledgehammer that is --no-mbtree.

Anyways, hoping to see (and do) some tests within the next days. Also hoping someone is sparing me the work of compiling a build myself.

24th January 2016, 19:25

Also hoping someone is sparing me the work of compiling a build myself.

GCC 6.0 build (outdated, grain patch now is applied)

mandarinka

24th January 2016, 21:05

That's all nice and well but x264 seems to do fine without the sledgehammer that is --no-mbtree.

x264 uses its mbtree by default everywhere but it isn't really great for everything. With things I encode, I disable it virtually every time. For --tune grain in x264, I suspect it is not very helpful, if it doesn't actually harm.

25th January 2016, 01:13

Can you please try this patch out? (https://patches.videolan.org/patch/12030/). This changes the behaviour of tune grain

First impression -- this patch changes output file without '--tune grain' option too.

With '--tune grain' the file size is much smaller (than without this patch) but quality is wrong. I watched results of encoding:
x265 --tune grain -D10 -p veryslow 720p50_parkrun_ter.y4m w.hevc
Sample file is not grainy but result is simply wrong.

nandaku2

25th January 2016, 05:34

First impression -- this patch changes output file without '--tune grain' option too.

With '--tune grain' the file size is much smaller (than without this patch) but quality is wrong. I watched results of encoding:
x265 --tune grain -D10 -p veryslow 720p50_parkrun_ter.y4m w.hevc
Sample file is not grainy but result is simply wrong.

With or without this patch, tune grain used on a non-grainy source doesnt make sense.

There are a number of user options to be corrected on this temp patch as of now - which is why it's not yet ready for 1.9. Please try this patch only on grainy videos with tune grain on.

The logic behind turning off cu-tree and AQ is that, on a grainy source every block of the frame has approximately similar texture (the actual content doesnt matter, since they're fully overridden by the grain). Our tests show this is vastly better at preventing grain patchiness.

Sagittaire

25th January 2016, 19:34

First impression -- this patch changes output file without '--tune grain' option too.

With '--tune grain' the file size is much smaller (than without this patch) but quality is wrong. I watched results of encoding:
x265 --tune grain -D10 -p veryslow 720p50_parkrun_ter.y4m w.hevc
Sample file is not grainy but result is simply wrong.

...... :readrule::readguid:

If you want make comparison, the first rule is to have same size.

Why make comparison with "much smaller" size. I did not even need to see the encoding that if the size difference is significant then of course that the quality will be lower. And moreover, you use grain tuning with source without grain and with high textural (spacial and temporal) variation. For these source AQ is really important for quality.

sneaker_ger

25th January 2016, 19:48

I'm also experiences broken results:

http://abload.de/img/original_8cjp3.png
http://abload.de/img/x265_vanilla_ydjoy.png
http://abload.de/img/x265_patched_hvkhu.png

Settings is 2pass --preset slower --tune grain --bitrate 7000. Patched build undershot bitrate but not enough to explain the extreme difference.

output files (https://mega.nz/#F!l00SDCZY!E39ux22Up96XuEJ-ZrZSEA)
source file (https://mega.co.nz/#!hh0nRLia!7BghO78Nto3t9jVz_AObXbHuFd5HlDn7k4XOb_acysc)
Source AviSynth script with cropping and trimming:
lwlibavvideosource("original.mkv")
assumefps(24000, 1001)
crop(0, 24, 0, -24)
Trim(634,1156)

25th January 2016, 21:13

With or without this patch, tune grain used on a non-grainy source doesnt make sense.

There are a number of user options to be corrected on this temp patch as of now - which is why it's not yet ready for 1.9. Please try this patch only on grainy videos with tune grain on.

I found 20 second sample www.msystem.waw.pl/x265/grain20s.mkv
Is it enough grainy/ugly for tests?

Motenai Yoda

25th January 2016, 22:02

@sneaker_ger have you tried with unpatched build and adding --rdoq-level 1 or 0?
I think it's a must for grainy sources.

LigH

26th January 2016, 10:17

Again, a "weekly" build with bugfixes; merge with stable.

x265 1.8+221-f548abe8eae8 (https://www.mediafire.com/download/fdt3f3w77khddbu/x265_1.8+221-f548abe8eae8.7z)
__

By the way ... there is really someone trying to create x265vfw (http://sourceforge.net/projects/mpxplay/files/x265vfw/) (currently incomplete, x265vfw_v100_x265b79_20160116 misses some MinGW/GCC DLLs, possibly no static build).

As if stuffing AVC into AVI was not yet pulling at the seams. And now HEVC in AVI; when will the seams burst? AVI is a tough leather.

Jamaika

26th January 2016, 11:38

By the way ... there is really someone trying to create x265vfw (http://sourceforge.net/projects/mpxplay/files/x265vfw/) (currently incomplete, x265vfw_v100_x265b79_20160116 misses some MinGW/GCC DLLs, possibly no static build).

As if stuffing AVC into AVI was not yet pulling at the seams. And now HEVC in AVI; when will the seams burst? AVI is a tough leather.
This is some crap. I don't even want to start.
rundll32.exe x265vfw.dll,Configurehttp://i65.tinypic.com/10cq8eq.png

Edit: Adding file 'libgcc_s_dw2-1.dll' doesn't correct the problem.
http://www.dll-files.com/dllindex/dll-files.shtml?libgcc_s_dw2-1

LigH

26th January 2016, 11:51

I told you, missing MinGW/GCC DLLs.

x265.cc

26th January 2016, 15:56

GCC 6.0 build: www.msystem.waw.pl/x265/x265-grain.7z

you should mention that gcc 6.0 is still experimental an not stable.
Afaik there are no performance optimizations for x86 in gcc 6.0.

26th January 2016, 19:03

you should mention that gcc 6.0 is still experimental an not stable.
Afaik there are no performance optimizations for x86 in gcc 6.0.

Yes, GCC 6.0 is in "regression and documentation fixes stage"
https://gcc.gnu.org/ml/gcc/2016-01/msg00168.html
and first stable version will be 6.1.

The output files in x265 encoding are the same for GCC 6.0, GCC 5.3 and VS 2015 builds, so there is no difference in stability (for x265).

Speed of encoding for CPU with SSE4 or better -- VS 2015 builds always win, for SSSE3 CPU -- GCC 6.0 wins. You can emulate SSSE3 CPU by '--asm SSSE3' option.

I attached simple speed results of emulated SSSE3 CPU for 10-bit encoding by your GCC 5.3 build and my GCC 5.3, GCC 5.3 SSSE3-CPU-msvcr120, GCC 6.0 and GCC 6.0 SSSE3-CPU-msvcr120.

divxmaster

27th January 2016, 04:14

I've been recently testing hardware decode of 10bit HEVC on skylake, with interesting results.
From what I understand skylake has 10bit hardware ASSISTED decode, using the inbuilt GPU.
Kabylake will have a full dedicated 10bit h/w decode module in the CPU.
Anyway, I've managed to get MPCHC to say H/W decoding, using dxva2 copyback.
BUT, it only saves around 2% cpu. Peaks at 17% in one scene sw and 15% hw.
So, not doing much. Curious if anyone else has tried it and got different results.

Cheers,
Divxmaster

kotuwa

27th January 2016, 08:50

Psy-RD
When the default value for Psy-RD is changed from 0.3 to 2.0,
The internal algorithms and internal stuff changed or not?

I mean, is 0.3 of new 1.8 builds is same as 0.3 in earlier 1.8 builds? Or close?
Or newer builds' 2.0 is closer to 0.3 in older builds?
or somewhere in the middle?
!?

Jamaika

27th January 2016, 09:32

I don't know how codec change the internal algorithms. I know that the frames has more details for placebo at psy-rd=2.00 and psy-rdoq=50.0.

LigH

27th January 2016, 10:14

I remember that these features have been improved to have less artifacts at higher strengths, therefore it was now safe enough to increase default values and allow a wider range. But I couldn't tell you if there is a kind of scaling.

27th January 2016, 17:56

If you want make comparison, the first rule is to have same size.

OK, so with options '--bitrate 10000 --tune grain' I encoded 20 seconds sample to file_1.hevc, then file_1.hevc to file_2.hevc and so on...

8-bit encoding with options '--bitrate 10000 --tune grain' iterated 100 times:
original sample: www.msystem.waw.pl/x265/grain20s.mkv
patched x265: www.msystem.waw.pl/x265/x265-8b-patch_100.hevc
clean x265: www.msystem.waw.pl/x265/x265-8b_100.hevc

clean x264: www.msystem.waw.pl/x265/x264-8b_100.264

I attached batch files used to encode.

x264 retains brightness and colors, x265 behaves weird.
-----------
10-bit encoding is better (after 100 iterations) and '--preset slow' is much better then '--preset medium'. I've tried also '--rdoq-level 1' option, but it is hard to tell if it is better or not.

10-bit encoding with options '-D10 --preset slow --bitrate 10000 --tune grain' iterated 100 times:
patched x265: www.msystem.waw.pl/x265/x265-10b-slow-patch_100.hevc

sneaker_ger

27th January 2016, 19:17

divxmaster

27th January 2016, 20:32

We have a thread dedicated to decoding performance. It also has results on Skylake if you are interested:
http://forum.doom9.org/showthread.php?p=1735604#post1735604

Great, thanks. I had a quick look around but couldn't see one under hevc, I see it is under 'software players' category.
Cheers.

greenfountain

29th January 2016, 06:11

OK, so with options '--bitrate 10000 --tune grain' I encoded 20 seconds sample to file_1.hevc, then file_1.hevc to file_2.hevc and so on...

8-bit encoding with options '--bitrate 10000 --tune grain' iterated 100 times:
original sample: www.msystem.waw.pl/x265/grain20s.mkv
patched x265: www.msystem.waw.pl/x265/x265-8b-patch_100.hevc
clean x265: www.msystem.waw.pl/x265/x265-8b_100.hevc

clean x264: www.msystem.waw.pl/x265/x264-8b_100.264

I attached batch files used to encode.

x264 retains brightness and colors, x265 behaves weird.
-----------
10-bit encoding is better (after 100 iterations) and '--preset slow' is much better then '--preset medium'. I've tried also '--rdoq-level 1' option, but it is hard to tell if it is better or not.

10-bit encoding with options '-D10 --preset slow --bitrate 10000 --tune grain' iterated 100 times:
patched x265: www.msystem.waw.pl/x265/x265-10b-slow-patch_100.hevc

From your script, I see you are encoding the content from the previously encoded bitstream for N iterations - why are you encoding it this way? any particular reason?

I downloaded your source and encoded the .mkv file with the same setting (--bitstream 10000 and tune grain). the results are much cleaner with no artifacts at all. applying the patch also shows the same results, with the grains improved in many of the B frames.

vanilla encode : https://www.dropbox.com/s/7o00sceo12uyd9j/grain20s_10000.hevc?dl=0

with latest grain patch : https://www.dropbox.com/s/2llmy9wvf5ogbgw/grain20s_10000_patch.hevc?dl=0

29th January 2016, 10:31

From your script, I see you are encoding the content from the previously encoded bitstream for N iterations - why are you encoding it this way? any particular reason?

Yes, I made 100 iterations of encoding with the same options. Reason -- there are quality imperfections in x265 encoding and after 100th iterations they are amplified and easier to see.

I downloaded your source and encoded the .mkv file with the same setting (--bitstream 10000 and tune grain). the results are much cleaner with no artifacts at all. applying the patch also shows the same results, with the grains improved in many of the B frames.

It looks like you made only 1st iteration (normal encoding) and it is much better than 100th iteration. I can't reproduce exactly your results because I can't find commit 'a53509b6fc0c' (from your encoded samples) and I'm surprise how you decode 'grain20s.mkv' sample to achieve fps=24000/1000?

LigH

29th January 2016, 11:45

Version 1.9 has been released as new milestone. From the developer mailing list:

x265 version 1.9 has now been released. This release supports many new features as well as additional assembly optimizations for Main12, intra prediction and SAO. Recently added features lookahead-slices, limit-refs and limit-modes have been enabled by default in the supported presets.

Full documentation is available at http://x265.readthedocs.org/en/stable/

========================================== New Features ==============================================
Quant offsets: This feature allows block level quantization offsets to be specified for every frame. An API-only feature.
--intra-refresh: Keyframes can be replaced by a moving column of intra blocks in non-keyframes.
--limit-modes: Intelligently restricts mode analysis.
--max-luma and --min-luma for luma clipping, optional for HDR use-cases
Emergency denoising is now enabled by default in very low bitrate, VBV encodes
=========================================== API Changes ==============================================
x265_frame_stats returns many additional fields: maxCLL, maxFALL, residual energy, scenecut and latency logging
--qpfile now supports frametype 'K"
x265 now allows CRF ratecontrol in pass N (N greater than or equal to 2)
Chroma subsampling format YUV 4:0:0 is now fully supported and tested
====================================== Presets and Performance ==========================================
Recently added features lookahead-slices, limit-modes, limit-refs have been enabled by default for applicable presets.
The default psy-rd strength has been increased to 2.0
Multi-socket machines now use a single pool of threads that can work cross-socket.

Thanks,
Deepthi Nandakumar
Engineering Manager, x265
Multicoreware, Inc

Only few more fixes for the new milestone:

x265 1.9+3-548a45bbf223 (https://www.mediafire.com/download/8sdpq21gboc7o3b/x265_1.9+3-548a45bbf223.7z)

LigH

29th January 2016, 14:39

x265_Project

29th January 2016, 19:19

Some Germans might find it funny — Fefe reports about x265 (http://blog.fefe.de/?ts=a859085f). He is usually notorious for ... uhm, let's say ... "alternative news" (calls himself "conspiracy theorizer" with a tongue-in-cheek), but his main profession is IT security, and he is in general interested in superior technologies.

His conclusion here: x265 became fast enough to be considered interesting for practical use.
Thanks for the link. Translated by Google...
Tue January 26 2016

[l] I have just a little playing around with X265, and wow the progress made! The Encoding Performance has always been massively unacceptable, but I can encode here just full HD material with 18 fps. This is the barrier, in the x264 was acceptable to me. Previously this was more like 3 fps in my experiments. VP9 is still in such regions.
This is a real breakthrough. I'm really impressed that've managed that. It will be interesting what will go there in the future that way.

HEVC is indeed practically usable by codec support her. Current graphics cards support real-time decoding them, sometimes even -Encoding (but since the quality of bandwidth per my experience can not keep up after).

My test runs here just with CRF 28, and he who comes in the test material out below 1000 kbit / sec.

1000 kbit / sec is the sound barrier, at the time as 640x360 dvdrip xvid with the first versions just went well. With the bandwidth makes X265 now Full HD. And that's on hardware today as soon as the time was on hardware of that time :-)

Boulder

31st January 2016, 19:55

Has anyone made any tests with --rd-refine?

agressiv

1st February 2016, 23:45

The default psy-rd strength has been increased to 2.0

Curious to the reasoning behind this? This increases file size substantially.

sneaker_ger

1st February 2016, 23:49

Raise crf or use --bitrate if you want smaller files.

Reasoning:
psyrd: change default to 2.0, increase range to 5.0

Earlier, high psy-rd caused artifacts, recent changes to mode decisions show an
improved response.
https://bitbucket.org/multicoreware/x265/commits/6f44cd5d00ff423b0e2f4817bc25b96d4191e82b

Motenai Yoda

2nd February 2016, 00:39

Version 1.9 has been released as new milestone. From the developer mailing list:
...
x265 now allows CRF ratecontrol in pass N (N greater than or equal to 2)
...

but how?
x265 [error]: Constant rate-factor is incompatible with 2pass

ps I think I've found the bottom of the causes, in the check
+ CHECK(param->rc.rateControlMode == X265_RC_CRF && param->rc.bStatRead && param->rc.vbvMaxBitrate == 0,
"Constant rate-factor is incompatible with 2pass");
"param->rc.vbvMaxBitrate" is checked, but vbv is enabled even with only the Level and/or Tier so not specifing the --vbv-maxrate it give error even if level with vbv restrictions is specified.
(but is forced this way only for param.rc.rateControlMode = X265_RC_CRF, when X265_RC_ABR (1 or n pass) only the bitrate is checked, here too, it's checked if more than high/main tier max, but lowered to high tier only even if main.. ???)

so either checking
CHECK(param->rc.rateControlMode == X265_RC_CRF && param->rc.bStatRead && (param->rc.vbvMaxBitrate == 0 && (param->levelIdc == 85 || param->levelIdc == 0)),
"Constant rate-factor is incompatible with 2pass");
or execute this check after enforceLevel()

ps 2 I found that bEnableSlowFirstPass isn't enabled by crf mode and x265_param_apply_fastfirstpass() is called
As I got it, it should do a slow first pass, with output and in a 2nd pass selectivelly reencode only some parts/gops
http://forum.doom9.org/showpost.php?p=1747571&postcount=2922
but It will do a brand new encode again, and with different settings I doubt it will be so reliable

also what should occour when in the 2nd pass the vbvmaxrate is setted much lower than in the 1st one? like 50k and 1k?

Atak_Snajpera

2nd February 2016, 15:57

Curious to the reasoning behind this? This increases file size substantially.

Better perceived quality in 2-pass mode (limited bitrate budget)
http://forum.doom9.org/showthread.php?p=1750936#post1750936

forum king

4th February 2016, 10:35

Hey all :)
needed some input if possible
can any of you great guys tell me these settings are from which encoder or GUI or whatever

wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=40 / rc-lookahead=20 / lookahead-slices=4 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.30 / rdoq-level=0 / psy-rdoq=0.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=25.5 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

the other day just for the sake of making an x265 encode of a video file of mine to convert it for my Note 4 , i tried using these settings in megui x265 encoder , but no matter what i always got an error
at this point i dont know much about the HEVC ,
if its possible then can anyone kindly convert them for megui or suggest a similar preset.

Thanks

Edit : i think this is from ffmpeg

LigH

4th February 2016, 10:52

forum king

4th February 2016, 11:05

These are the encoding parameters from the inside of x265; they are not 1:1 equal to command line parameters provided to x265.exe from the outside... Just as an example, you can probably group several of these options to preset and tuning meta-parameters, and many will be defaults you could omit from a command line call.

I believe Selur wrote a tool which can calculate from internal parameters back to command lines. But I am not sure how up-to-date with x265 this tool is...

Thanks mate ,
But plz excuse my utter ignorance , can you may be point out which of these can be added to the custom field in megui x265 preset , i dont have a clue whatsoever about which will be accepted in megui and which wont.

would be grateful ,

Thanks

LigH

4th February 2016, 11:16

Why this effort? ... Do you want to try to copy options from one encoded movie to another? You should not do this. Your movie may need different options. You may prefer different options as compromise between encoding speed and quality retention. As a beginner, rely on "preset" and "tune" only, add VBV when compatibility to playback devices is required. To use more specific parameters, you really should know why they would be better than the preset defaults.

Sorry to disappoint you, but I will not spend a lot of time analyzing this internal parameter set. I see no use in doing so.

divxmaster

5th February 2016, 04:43

@forumking,
I suggest you use cmd.exe instead, I'm not even sure if megui can utilize x265 properly.
You will need to know how to create a .d2v and use ars calculator to work out your SAR.
if not, google it. I am presuming you are using a dvd vob.
I have done a lot of work optimizing for mobile devices, like your note 4.
I use command:
avs4x26x -L x265.exe --crf 28 --psy-rd 0.3 --preset slow --fps %fps% --b-intra --ref 5 --bframes 5 --max-merge 5 --nr-intra 400 --nr-inter 400 --sar %sar% --no-open-gop --min-keyint 23 --keyint 288 --deblock -1:-1 -o "output.hevc" "%source%.avs"

This works very well at super low bit rates. Again this is for mobile phone screen sizes only.
Change %fps%, %sar% and %source% to the correct values first.
If you need to deinterlace first, this is a whole lot more complicated.
--psy-rd 0.3 is for the newer 1.9 version. you don't need 2.0 psy-rd for small screens.

google how to use mp4box to turn the hevc into a mp4. Make sure you use 10bit x265.

Cheers
Divxmaster

nandaku2

5th February 2016, 05:48

@Motenai Yoda,

Yes, at present CRF is allowed in N-pass only when VBV is enabled (this condition should have been noted in my 1.9 release notes, apologies). We're working on some ratecontrol modifications which will remove this restriction.

forum king

5th February 2016, 06:16

Thanks a lot @Ligh and Divxmaster,
The thing is I was recently gifted a box set of prison break and a couple of miniseries,
A friend of a friend encoded the first episode and it looked awesome on my pc as well as my mobile, so to be able to watch em all on the go, I am trying to do this.
I am aware about megui only, that too just Elementary, that's was seeking help.

The guy who did it had shared the file like a couple of months back, at the time I didn't know how to play the X265, but recently when I tried I was surprised with the ratio. The guy is unreachable since then.

If I knew how to use x265 using cmd or some other application like ffmpeg, I would not have bothered you guys.

Still thanks a lot Divxmaster for the share, god bless mate.

Sent from my LGUS990 using Tapatalk

5th February 2016, 23:11

x265 code in many parts is exactly copy of x264 code. 28 Jan 2009 in x264 appears abs2 function -- http://git.videolan.org/?p=x264.git;a=commitdiff;h=0e43d5d995bb436a63934d70792e481770f406d3

After adopting this function to 10-bit encoding (http://git.videolan.org/?p=x264.git;a=commitdiff;h=8efd67c034190b415174fd03c3cfef4768345f11) it is without changes in x264 and x265 code.

The problem is that it calculates abs wrong. Consider pair (x=-1, y=0). This function returns pair (1, 1) instead of (1, 0).

littlepox

6th February 2016, 07:34

It seems v1.9 is less efficient especially when used in dual NUMAs(CPUs) system compared to v1.8. We deployed the same parameters (change in the presets incorporated so that every single parameter is the same), the speed (fps) has dropped by 15%.

Any idea why this happens?

x265 -D 10 --preset slower --crf 16.0 --ctu 32 --max-tu-size 16 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 10 --aq-mode 1 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --input-depth 10 --deblock -2:-2 --qg-size 16 --vbv-bufsize 28000 --vbv-maxrate 25000 --limit-refs 0 --no-limit-modes

MasterNobody

6th February 2016, 10:12