New milestone: v2.5
x265 version 2.5, which includes improvements to grain handling, and improved CSV logging feature which is now built into the library.
Version 2.5 can be downloaded from here (md5: 192e54fa3068b594aa44ab2b703f071d).Full documentation is available at http://x265.readthedocs.io/en/stable/
Release Notes for Version 2.5
=======================
Encoder enhancements
--------------------------------
1. Improved grain handling with --tune grain option by throttling VBV operations to limit QP jumps.
2. Frame threads are now decided based on number of threads specified in the --pools, as opposed to the number of hardware threads available. The mapping was also adjusted to improve quality of the encodes with minimal impact to performance.
3. CSV logging feature (enabled by --csv) is now part of the library; it was previously part of the x265 application. Applications that integrate libx265 can now extract frame level statistics for their encodes by exercising this option in the library.
4. Globals that track min and max CU sizes, number of slices, and other parameters have now been moved into instance-specific variables. Consequently, applications that invoke multiple instances of x265 library are no longer restricted to use the same settings for these parameter options across the multiple instances.
x265 can now generate a seprate library that exports the HDR10+ parsing API. Other libraries that wish to use this API may do so by linking against this library. Enable ENABLE_HDR10_PLUS in CMake options and build to generate this library.
5. SEA motion search receives a 10% performance boost from AVX2 optimization of its kernels.
6. The CSV log is now more elaborate with additional fields such as PU statistics, average-min-max luma and chroma values, etc. Refer to documentation of --csv for details of all fields.
7. x86inc.asm cleaned-up for improved instruction handling.
API changes
-----------------
1. New API x265_encoder_ctu_info() introduced to specify suggested partition sizes for various CTUs in a frame. To be used in conjunction with --ctu-info to react to the specified partitions appropriately.
2. Rate-control statistics passed through the x265_picture object for an incoming frame are now used by the encoder.
3. Options to scale, reuse, and refine analysis for incoming analysis shared through the x265_analysis_data field in x265_picture for runs that use --analysis-reuse-mode load; use options --scale, --refine-mv, --refine-inter, and --refine-intra to explore.
4. VBV now has a deterministic mode. Use --const-vbv to exercise.
Bug fixes
-------------
1. Several fixes for HDR10+ parsing code including incompatibility with user-specific SEI, removal of warnings, linking issues in linux, etc.
2. SEI messages for HDR10 repeated every keyint when HDR options (--hdr-opt, --master-display) specified.
Happy compressing!
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 751 to 780 of 782
Thread
-
Does anyone know if AVX-512 will be added anytime in the near future (next several months or couple years)? I'm getting ready to build a new computer and trying to decide between Intel and AMD, and one of the factors I'm looking at is that Intel has AVX-512 instructions and AMD does not. If it's going to be a couple years at least before it's added to x265, it probably won't matter much, but if there's a good chance of it being implemented in the next year or so, it would be a good reason to go with Intel.
-
The sources have been changed to use NASM instead of YASM (which seems to be more or less obsolete, feature-wise; altering YASM to make it support AVX-512 may be too much efforts, their developers stated). A first step is done...
-
So I haven't observed any quality increase since build 1.2. 2.6 has same quality as 1.2. Are any of these new settings/fixes actually doing anything? My source is 480p anime as well as real video.
-
Insufficient details. No complete command lines, no sample clips to compare for our eyes too. Well possible your selected parameter set doesn't show obvious differences because the bitrate is e.g. either too high to see any artifacts, or too low to see less, or you did not use any new useful features for the specific material to be compressed, or ... or ...
-
I've done 64, 128 and 256 kb/s. 64 sucks, 128 is pretty good and 256 looks flawless. All three at the same bitrate look exactly the same for all x265 versions.
Commandline:
Code:avs4x26x --x26x-binary x265_12 "TouhouAnime.avs" --pass 1 --bitrate 128 --tune ssim --ref 1 --rd 2 --ctu 64 --no-rect --no-amp --early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 1 --me dia --subme 2 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao -o "Touhou Anime1.2 2pass.hevc" avs4x26x --x26x-binary x265_12 "TouhouAnime.avs" --pass 2 --bitrate 128 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao -o "Touhou Anime1.2 2pass.hevc" avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" --pass 1 --bitrate 129 --tune ssim --ref 1 --rd 2 --ctu 64 --no-rect --no-amp --early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 1 --me dia --subme 2 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 2pass.hevc" avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" --pass 2 --bitrate 129 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 2pass.hevc"
-
Is there a difference when you use a way higher bitrate and the same avisynth script source? (To be sure that the source has details that could be saved with a newer version,...)
-> looking at the lower bitrates for that source might be more interesting to see differencesusers currently on my ignore list: deadrats, Stears555 -
I don't understand the first question. I always use the same source for the same test. What is a "way higher bitrate"?
At the same bitrate, quality is always the same no matter the version. Quality metrics have remained nearly identical. Using 10-bit makes no difference.
I'll show you 64 kb/s samples tomorrow if you're more interested in that. -
At a bit rate that is high enough for a specific source even MPEG-1 can be on par with H.265.
So the question is does your source have more details than the reencode? Since you wrote that 256kBit/s seems to be flawless my fear is that it 256 'too' high for the source to gain from better decisions during compression.
You already wrote that the low bitrate (64) version 'sucks', so the question is do all the encodes of the same bitrate look to you the same or can you differentiate whether for example a 100kBit/s version was encoded using x264 version 1.2 or 2.6, also you only state the quality is the same at the same bitrate, but is the encoding time also the same?
Cu Selurusers currently on my ignore list: deadrats, Stears555 -
The MPEG-1 bitrate would need to be 650 kb/s to match the quality of 64 kb/s H.265 and 3000 kb/s to match H.265 at 256 kb/s.
Yes, the source does still have more details but you would need the source to directly compare.
Correct, I can't tell the quality apart. The outputs of all versions look the same. 2.6 does not do better than 1.2.
No, 2.6 is twice as slower than 1.2 but the same quality. Version 1.8 is the fastest, but again; same quality.
Here's the 64 kb/s tests.
Code:M:\>avs4x26x --x26x-binary x265_12 "TouhouAnime.avs" --pass 2 --bitrate 66 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-dept h 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b -adapt 2 --bframes 8 --cutree --sao -o "Touhou Anime1.2 2pass.hevc" avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54] avs [info]: Video colorspace: YV12 avs [info]: Video resolution: 720x480 avs [info]: Video framerate: 24000/1001 avs [info]: Video framecount: 5000 avs4x26x [info]: "x265_12" - --pass 2 --bitrate 66 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --c utree --sao -o "Touhou Anime1.2 2pass.hevc" --frames 5000 --fps 24000/1001 --input-res 720x480 --inp ut-csp i420 yuv [info]: 720x480 fps 24000/1001 i420p8 unknown frame count x265 [info]: HEVC encoder version 1.2+305-66ed81577483 x265 [info]: build info [Windows][GCC 4.8.1][32 bit] 8bpp x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 x265 [info]: WPP streams / pool / frames : 8 / 8 / 3 x265 [info]: Main profile, Level-3 (Main tier) x265 [info]: CU size : 64 x265 [info]: Max RQT depth inter / intra : 3 / 3 x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4 x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40 x265 [info]: Lookahead / bframes / badapt : 0 / 8 / 2 x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 5 x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-66 kbps / 1.0 / 1 x265 [info]: tools: rect amp rd=6 lft sao-lcu signhide tskip stats-read x265 [info]: frame I: 35, Avg QP:26.77 kb/s: 2600.50 x265 [info]: frame P: 960, Avg QP:29.89 kb/s: 170.75 x265 [info]: frame B: 4005, Avg QP:37.78 kb/s: 18.99 x265 [info]: global : 5000, Avg QP:36.19 kb/s: 66.20 x265 [info]: Weighted P-Frames: Y:0.7% UV:0.5% x265 [info]: Weighted B-Frames: Y:0.3% UV:0.2% x265 [info]: consecutive B-frames: 5.0% 5.0% 3.5% 29.4% 16.5% 22.6% 6.5% 6.9% 4.4% encoded 5000 frames in 823.97s (6.07 fps), 66.20 kb/s M:\>avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" --pass 2 --bitrate 67 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-dept h 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b -adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-siz e 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2 .6 2pass.hevc" avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54] avs [info]: Video colorspace: YV12 avs [info]: Video resolution: 720x480 avs [info]: Video framerate: 24000/1001 avs [info]: Video framecount: 5000 avs4x26x [info]: "x265_26" - --pass 2 --bitrate 67 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --c utree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2 --loo kahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 2pass.hevc" --frames 5000 --fps 24000/1001 --input-res 720x480 --input-csp i420 yuv [info]: 720x480 fps 24000/1001 i420p8 unknown frame count raw [info]: output file: Touhou Anime2.6 2pass.hevc x265 [info]: HEVC encoder version 2.6+2-32e6f04b8713 x265 [info]: build info [Windows][GCC 7.2.0][32 bit] 8bit+10bit+12bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 x265 [info]: Main profile, Level-3 (Main tier) x265 [info]: Thread pool created using 8 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(8 rows) x265 [warning]: Source height < 720p; disabling lookahead-slices x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4 x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1 x265 [info]: References / ref-limit cu / depth : 5 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : ABR-67 kbps / 0.60 x265 [info]: tools: rect amp limit-modes rd=6 rdoq=2 rd-refine tskip signhide x265 [info]: tools: tmvp b-intra strong-intra-smoothing deblock(tC=1:B=1) sao x265 [info]: tools: stats-read x265 [info]: frame I: 36, Avg QP:27.84 kb/s: 2446.41 x265 [info]: frame P: 972, Avg QP:35.72 kb/s: 176.38 x265 [info]: frame B: 3992, Avg QP:39.96 kb/s: 18.45 x265 [info]: Weighted P-Frames: Y:0.1% UV:0.0% x265 [info]: Weighted B-Frames: Y:0.4% UV:0.2% x265 [info]: consecutive B-frames: 6.4% 5.0% 3.5% 29.3% 17.1% 20.8% 6.7% 6.2% 5.0% encoded 5000 frames in 1603.43s (3.12 fps), 66.63 kb/s, Avg QP:39.04
-
Some screenshots of the 64 kb/s encode:
1.2 actually looks slightly better here IMO but overall they're about the same. -
Yes, the source does still have more details but you would need the source to directly compare.
The colors are 'off' between you source and your encodes, is this intended? If it is intended, you should take screenshots of the source after processing and before reencoding,...
You might want to set lookahead for both encodes to the same value.
Cu Selur
Ps.: Why don't you use 10bit encoding?
You might want to add VUI signaling (and may be vbv/profile/level-signaling).users currently on my ignore list: deadrats, Stears555 -
Not feasible. The source is 800MB and my upload speed is shit. I can give a torrent to the source and then provide my Avisynth script but I don't know if this movie is copyrighted or not. Hell, I haven't watched it in the 2 years I had it, it just makes a good test video.
The colors are 'off' between you source and your encodes, is this intended?
You might want to set lookahead for both encodes to the same value.
That's why I'm puzzled. Despite all the new features, the quality is not increasing. Why?
Ps.: Why don't you use 10bit encoding?
This particular 10-bit encode I attached seems to have been a CRF rather than 2pass encode so it's apples and oranges but my question remains unanswered as to why the quality is stagnating no matter the configuration.
You might want to add VUI signaling (and may be vbv/profile/level-signaling). -
I don't know what you're talking about.
I used Vapoursynth for example:
Code:# Imports import vapoursynth as vs core = vs.get_core() # Loading Plugins core.std.LoadPlugin(path="G:/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/vslsmashsource.dll") clip12 = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/Touhou Anime1.2 2pass.mkv", format="YUV420P8", cache=0) clip12 = core.resize.Point(clip12, matrix_in_s="470bg") clip12 = core.std.SetFrameProp(clip=clip12, prop="_ColorRange", intval=1) clip12 = core.sub.Subtitle(clip=clip12, text="1.2"); clip26 = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/Touhou Anime2.6 2pass.mkv", format="YUV420P8", cache=0) clip26 = core.resize.Point(clip26, matrix_in_s="470bg") clip26 = core.std.SetFrameProp(clip=clip26, prop="_ColorRange", intval=1) clip26 = core.sub.Subtitle(clip=clip12, text="2.6"); clip1210 = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/TouhouAnime x265 1.2 10bit max CRF.mkv", format="YUV420P8", cache=0) clip1210 = core.resize.Point(clip1210, matrix_in_s="470bg") clip1210 = core.std.SetFrameProp(clip=clip1210, prop="_ColorRange", intval=1) clip1210 = core.sub.Subtitle(clip=clip1210, text="1.2 - 10bit"); clip2010 = core.lsmas.LWLibavSource(source="C:/Users/Selur/Desktop/TouhouAnime x265 2.0 10bit max CRF.mkv", format="YUV420P8", cache=0) clip2010 = core.resize.Point(clip2010, matrix_in_s="470bg") clip2010 = core.std.SetFrameProp(clip=clip2010, prop="_ColorRange", intval=1) clip2010 = core.sub.Subtitle(clip=clip2010, text="2.0 - 10bit"); clip1 = core.std.StackHorizontal([clip12,clip26]) clip2 = core.std.StackHorizontal([clip1210,clip2010]) clip = core.std.StackVertical([clip1, clip2]) clip.set_output()
I've used identical parameters for all versions except ones that didn't exist until later. Since lookahead is featured in all the tested versions, they've all had the same default value of 40.
Code:x265 [info]: Lookahead / bframes / badapt : 0 / 8 / 2
Code:x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
That's why I'm puzzled. Despite all the new features, the quality is not increasing. Why?
Thus they will slow down looking for details, but in the end find nothing to improve. Or you are simply missing the improvements,.. attached a few screenshots,... (from the script above)
What's that?
http://x265.readthedocs.io/en/default/cli.html#vui-video-usability-information-options
http://x265.readthedocs.io/en/default/cli.html#profile-level-tier
VUI is important for correct color during decoding,...
This particular 10-bit encode I attached seems to have been a CRF rather than 2pass encode so it's apples and oranges
That a side you used 2.0 instead of 2.6 this time so the random screenshots I posted can't be compared that well.
Tried that, it isn't any better quality and it's slow as **** on a 32-bit system.
-> Since I can't offer enough details for others to reproduce your finding. I can't really help since it's more and more wild guessing.
Wish you luck with hunting this down and may be someone else is willing to try to reproduce this.
Cu Selurusers currently on my ignore list: deadrats, Stears555 -
Hey, ignore the 1.2 10-bit encode I uploaded. It is visibly worse quality and I should've checked my journal before posting that. I uploaded the 2.0 10-bit encode because it was all I kept and I didn't feel like waiting 3 hours to produce a new 2.6 10-bit encode.
But notice the 2.0 10-bit encode is not better quality than the 1.2 8-bit encode. That alone proves that 10-bit is not improving anything here.
The movie Touhou Summer Day's Dream is fan-made so I believe you can legally download it. Once you get it, the Avisynth script is
Code:ffvideosource("M:\Musou Kakyou - A Summer Day's Dream.mkv") trim(5000,9999) spline64resize(720,480)
I don't know why the CMD log says 0 lookahead but it is not correct. I clearly used lookahead 40 in my encoding script. You can confirm this with MediaInfo. I tried changing it to 41 to see if the CMD log would change but it remained 0. Changed it to 30, still 0.
But regardless of this, if 1.2 with no lookahead is doing slightly better than 2.6 with 40 lookahead, what does that tell you?
It once again begs the question: why do the new x265 versions suck so bad?
You might want to read up on those.
http://x265.readthedocs.io/en/default/cli.html#vui-video-usability-information-options
http://x265.readthedocs.io/en/default/cli.html#profile-level-tier
VUI is important for correct color during decoding,...
That a side you used 2.0 instead of 2.6 this time so the random screenshots I posted can't be compared that well.
Wish you luck with hunting this down and may be someone else is willing to try to reproduce this. -
Here's a 2.6 10-bit encode, for apples'n'apples.
Code:M:\>avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" -D 10 --pass 1 --bitrate 67 --tune ssim --ref 1 --rd 2 --ctu 64 --no-rect --no-amp --early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-i nter-depth 3 --tskip --max-merge 1 --me dia --subme 2 --merange 57 --weightp --weightb --rc-lookahea d 40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --mi n-cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touho u Anime2.6 10bit 2pass.hevc" avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54] avs [info]: Video colorspace: YV12 avs [info]: Video resolution: 720x480 avs [info]: Video framerate: 24000/1001 avs [info]: Video framecount: 5000 avs4x26x [info]: "x265_26" - -D 10 --pass 1 --bitrate 67 --tune ssim --ref 1 --rd 2 --ctu 64 --no-re ct --no-amp --early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --m ax-merge 1 --me dia --subme 2 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bfram es 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 10bit 2pass.h evc" --frames 5000 --fps 24000/1001 --input-res 720x480 --input-csp i420 yuv [info]: 720x480 fps 24000/1001 i420p8 unknown frame count raw [info]: output file: Touhou Anime2.6 10bit 2pass.hevc x265 [info]: HEVC encoder version 2.6+2-32e6f04b8713 x265 [info]: build info [Windows][GCC 7.2.0][32 bit][noasm] 10bit x265 [info]: using cpu capabilities: none! x265 [warning]: --tskip disabled, requires --rdlevel 3 or higher x265 [warning]: --rd-refine disabled, requires RD level > 4 and adaptive quant x265 [info]: Main 10 profile, Level-3 (Main tier) x265 [info]: Thread pool created using 8 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(8 rows) x265 [warning]: Source height < 720p; disabling lookahead-slices x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra x265 [info]: ME / range / subpel / merge : dia / 57 / 2 / 1 x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1 x265 [info]: References / ref-limit cu / depth : 1 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : ABR-67 kbps / 0.60 x265 [info]: tools: limit-modes rd=2 rdoq=2 early-skip signhide tmvp b-intra x265 [info]: tools: strong-intra-smoothing deblock(tC=1:B=1) sao stats-write x265 [info]: frame I: 35, Avg QP:29.08 kb/s: 2064.28 x265 [info]: frame P: 954, Avg QP:35.07 kb/s: 187.16 x265 [info]: frame B: 4011, Avg QP:40.07 kb/s: 21.99 x265 [info]: Weighted P-Frames: Y:4.6% UV:4.3% x265 [info]: Weighted B-Frames: Y:2.6% UV:2.5% x265 [info]: consecutive B-frames: 7.0% 4.8% 4.1% 27.8% 12.3% 22.2% 9.0% 7.4% 5.4% encoded 5000 frames in 453.95s (11.01 fps), 67.80 kb/s, Avg QP:39.04 M:\> M:\>avs4x26x --x26x-binary x265_26 "TouhouAnime.avs" -D 10 --pass 2 --bitrate 67 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inte r-depth 3 --tskip --max-merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min- cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 10bit 2pass.hevc" avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54] avs [info]: Video colorspace: YV12 avs [info]: Video resolution: 720x480 avs [info]: Video framerate: 24000/1001 avs [info]: Video framecount: 5000 avs4x26x [info]: "x265_26" - -D 10 --pass 2 --bitrate 67 --tune ssim --ref 5 --rd 6 --ctu 64 --rect --amp --no-early-skip --b-intra --no-tskip-fast --tu-intra-depth 3 --tu-inter-depth 3 --tskip --max- merge 4 --me star --subme 4 --merange 57 --weightp --weightb --rc-lookahead 40 --b-adapt 2 --bframes 8 --cutree --sao --no-rskip --limit-modes --rd-refine --limit-refs 1 --min-cu-size 8 --rdoq-level 2 --lookahead-slices 1 --deblock=1:1 --no-fast-intra --psy-rdoq 0 -o "Touhou Anime2.6 10bit 2pass10bi t.hevc" --frames 5000 --fps 24000/1001 --input-res 720x480 --input-csp i420 yuv [info]: 720x480 fps 24000/1001 i420p8 unknown frame count raw [info]: output file: Touhou Anime2.6 10bit 2pass.hevc x265 [info]: HEVC encoder version 2.6+2-32e6f04b8713 x265 [info]: build info [Windows][GCC 7.2.0][32 bit][noasm] 10bit x265 [info]: using cpu capabilities: none! x265 [info]: Main 10 profile, Level-3 (Main tier) x265 [info]: Thread pool created using 8 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 3 / wpp(8 rows) x265 [warning]: Source height < 720p; disabling lookahead-slices x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4 x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1 x265 [info]: References / ref-limit cu / depth : 5 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : ABR-67 kbps / 0.60 x265 [info]: tools: rect amp limit-modes rd=6 rdoq=2 rd-refine tskip signhide x265 [info]: tools: tmvp b-intra strong-intra-smoothing deblock(tC=1:B=1) sao x265 [info]: tools: stats-read x265 [info]: frame I: 35, Avg QP:27.12 kb/s: 2451.31 x265 [info]: frame P: 954, Avg QP:35.38 kb/s: 177.87 x265 [info]: frame B: 4011, Avg QP:39.59 kb/s: 19.29 x265 [info]: Weighted P-Frames: Y:0.8% UV:0.3% x265 [info]: Weighted B-Frames: Y:0.7% UV:0.4% x265 [info]: consecutive B-frames: 7.0% 4.8% 4.1% 27.8% 12.3% 22.2% 9.0% 7.4% 5.4% encoded 5000 frames in 5176.15s (0.97 fps), 66.57 kb/s, Avg QP:38.70
-
I just wanted to write that I have experimented a bit with .h265 encoding via VidCoder and I think it is a good format. I find it takes twice as long as what the video is to encode but you get reduced file size and a nice looking and sounding video. I am sticking with .h264 for the most part but I want to say thank you to the developers. It is nice to have options and .h265 shows a lot of promise.
-
Selur?I can't really help since it's more and more wild guessing.
@Moderators: Would be nice if this whole discussion could be moved into another thread since it's spamming this thread quite a bit,..users currently on my ignore list: deadrats, Stears555 -
Well I was hoping you would grab the source and try some tests. It never occurred to me until now that I could just split the part in direct stream copy and post it to avoid pasting 800MB. Here it is: https://www.sendspace.com/file/dcp19b
DoCode:spline64resize(720,480) trim(8,5007)
Please also use the same encoding settings.
And how is this spam? The topic is the x265 encoder, what are we discussing?Last edited by Aludin; 7th Jan 2018 at 00:25.
-
It means that this thread is mainly for announcing a new version and explaining changes between versions.
But questions how to use the encoder in specific cases usually develops into a longer discussion, which could make people miss brief announcements in between posts with long code blocks and image lists. Such questions deserve a separate thread. -
Isn't there already a thread for that? https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds
-
That's for binaries built with MSYS / MinGW / GCC. There could also be binaries built with other compilers and environments.
IMHO, one more thread is less anoying than a huge growing and derailing one. -
307 patches with AVX-512 (and other improved assembly) code uploaded to the developer mailing list. That will take a little while to review. -
The AVX-512 patches are committed.
Unfortunately, they don't compile for the x86 (Win32) target architecture (assembler optimized code was still enabled for 8-bit depth core). A "bailout" to skip AVX-512 assembler code completely in 32-bit mode may be required. -
Belated from releasenotes.rst:
Code:Version 2.9 =========== Release date - 05/10/2018 New features ------------- 1. Support for chunked encoding :option:`--chunk-start and --chunk-end` Frames preceding first frame of chunk in display order will be encoded, however, they will be discarded in the bitstream. Frames following last frame of the chunk in display order will be used in taking lookahead decisions, but, they will not be encoded. This feature can be enabled only in closed GOP structures. Default disabled. 2. Support for HDR10+ version 1 SEI messages. Encoder enhancements -------------------- 1. Create API function for allocating and freeing x265_analysis_data. 2. CEA 608/708 support: Read SEI messages from text file and encode it using userSEI message. Bug fixes --------- 1. Disable noise reduction when vbv is enabled. 2. Support minLuma and maxLuma values changed by the commandline.
-
x265 2.9+14-3023bd8b05c0 (MSYS2, MinGW32 + GCC 7.4.0 / MinGW64 + GCC 8.2.1)
support for Dolby Vision profile 5 and RPU multiplexing; Cutree offset for analysis reuse -
Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.
Similar Threads
-
[HEVC] x265.EXE: mingw builds
By El Heggunte in forum Video ConversionReplies: 2221Last Post: 9th Feb 2021, 02:18 -
HEVC Encoder by Strongene Lentoid
By vhelp in forum Video ConversionReplies: 126Last Post: 19th May 2017, 13:58 -
theX.265 (a free HEVC) codec. Have you ever tried that HEVC encoder? (HELP)
By Stears555 in forum Video ConversionReplies: 41Last Post: 16th Sep 2013, 12:15 -
HEVC x265 Decoder
By enim in forum Newbie / General discussionsReplies: 5Last Post: 19th Aug 2013, 13:58 -
MulticoreWare Annouces x265/HEVC Mission Statement
By enim in forum Latest Video NewsReplies: 4Last Post: 9th Aug 2013, 23:09