x265 HEVC Encoder

[Selur]

Means, version 0.8+263-1fc0fda2b08b is considered a stable step towards the milestone of v0.9.

Nope, it means that all other upcoming 0.8 releases are ment for bug fixes, tunings and cosmetic changes.
Feature freeze doesn't say anything about stability. (may be the planned quality improvement are coming now or may be these are postponed till 0.9 arrives?)

[LigH.de]

Well, "merging stable with default" was the flag that showed me some importance of this revision.

[LigH.de]

Another (more or less) "stable" build will be x265 version 0.8+266-3f27daf35506. It publishes two previously not yet so official parameters:

   --dither                      Enable dither if downscaling to 8 bit pixels. Default disabled

   --[no-]weightb                Enable weighted prediction in B slices. Default disabled

[x265]

x265 0.9 is a regularly scheduled bug fix release. Many bugs have been fixed since the 0.8 tag, primarily in rate control and 10bit encodes. A race hazard on POSIX systems was fixed, and several non-determinism problems were resolved.

= API Changes =
* the stride of x265_picture is now in units of bytes, not pixels
* VUI configurables were moved into a param.vui sub-struct
* unimplemented VUI options removed
* bRepeatHeaders option added (inserts VPS+SPS+PPS each keyframe)
* fast-decode tune option added
* x265_encoder_headers() returns NAL byte count on success

= CLI Changes =
* --dither option to improve quality of pixel downshifts
* --cpuid replaced with x264 compatible --asm option
* --crf-max <float> added
* improved --help documentation, plus new online documentation
* **experimental** --interlaceMode <prog|tff|bff>
* **experimental** --weightb

= New Features =
* experimental support for interlaced content (field coding)
* experimental weightb support

We now have online documentation for this release http://x265.readthedocs.org/en/0.9/
plus http://x265.readthedocs.org/en/default/ and http://x265.readthedocs.org/en/stable for the two development branches.

See the online manual for full documentation of CLI (and API) options

Our focus for the near future remains on visual quality and rate control improvements.

[Selur]

Our focus for the near future remains on visual quality and rate control improvements.

Does this include 2pass encoding?

[x265]

Our focus for the near future remains on visual quality and rate control improvements.

Does this include 2pass encoding?

At some point. It's not imminent. There are a number of other higher priorities.

[z-machine95]

for now i'm encoding film between 2-3 h at 2500 single pass with this setting:

--threads 8 --input - --input-res 1920x800 --fps 23.976 --frames 228505 --merange 60 --no-amp --min-keyint 1 --b-adapt 1 --bitrate 2800 --colormatrix bt709 --output "H:\HP1_new_20_27_05_6410_01.265"
x265 [info]: HEVC encoder version 0.8+98-4fdcea7426f1
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames : 13 / 8 / 3
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 60 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 1 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 1
x265 [info]: b-pyramid / weightp / refs : 1 / 1 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-2800 kbps / 1.0 / 1
x265 [info]: tools: rect rd=3 lft sao-lcu sign-hide

but it with a i7 2600k at 4.6 Ghz with 16 Gb ram 1600 Mhz it takes near 8 hours....
i use the fast preset and the quality is good but the encoding time is too long, it's better to choose a faster preset with an higher bitrate or a slower preset with a lower bitrate? i don't know, ultra fast preset at 3500 Kbps is similar to fast preset at 2800? i need mkv under 3.5 Gb with 2 audio track ac3 at 448 Kbps... so the video track must be under 2.5 Gb.

thank you anyway!!!!!!!!!

Edit: i use last build of hybrid by selur...

[El Heggunte]

Hmmmmmmm......

We were at the NAB show in Las Vegas last week, giving demonstrations to many of the companies attending, showing x265 encodes of popular video sequences side by side with x264 encodes (the gold standard for quality today). Attendees were blown away by the quality of x265. We demonstrated 2 streams played back in sync, showing the middle 50% of two 4K clips on a 4K monitor. Here is a photo of our demo...

Sample frame grabs from Crowd_Run4K50 @ 4 Mbps are here... http://x265.org/CrowdRun4K_4Mbps.7z
You can repeat these tests yourself, using the SVT clips from http://media.xiph.org/video/derf/ - Crowd Run, Old Town Cross, Ducks Take Off, In To Tree.... take your pick.

H.265 provides for much higher video coding accuracy. The thing you will notice is that x265 encodes don't have all of the temporal artifacts of H.264. x265 is typically winning comparisons against x264 even at half the bit rate. There were cases where x265 was preferred even at 1/4 the bit rate
(Crowd Run 4K - x265 veryslow 4 Mbps vs x264 veryslow @ 16 Mbps), due to the lack of temporal artifacts and macroblocking in x265.

[LigH.de]

Sounds like an accolade, if the comparison was fair. I'll try to repeat it, but it will cost a lot of time, I fear.
__

5.8 GB per 2160p Y4M. Scheduling downloads for my absence during Easter...

[x265]

Sounds like an accolade, if the comparison was fair. I'll try to repeat it, but it will cost a lot of time, I fear.
__

5.8 GB per 2160p Y4M. Scheduling downloads for my absence during Easter...

We would be interested in seeing your results from tests with any good source content (ideally, uncompressed or very lightly compressed source material). We also demo'ed comparisons with 1080P material like Riverbed, Station2, Sintel, and Big Buck Bunny. Our test encodes were done with ABR rate control and the veryslow preset for both x264 and x265.

[gonca]

Crowd running

x265

RAM 6,687,360 K --- 6,699,060 K

Hybrid: homepage
Forum: public forum
Regarding problems please read: needed infos
Donate: via PayPal
 ->disabling qaac support since 'Apple Application Support' is not installed,...
Finished initialization, finished after 1.014s

Filtering input files,..
Analysing 1 input files,...
analyzing: crowd_run_2160p50.y4m
Analyzing I:\crowd_run_2160p50.y4m with raw analyser,... 
 reading the whole input file to get the frame count,..
starting auto routines for source number: 1
added new info node (Chapter selection) to stream,..
 -> finished auto routines for source number 1.
Input is completely analysed,...
Creating jobs for 1 sources,...
 -> Creating jobs for source 1,...
 -> Generating calls for: W:\OUTPUT\crowd_run_2160p50.mkv
adding x265 calls for source: 1
createJobs for W:\OUTPUT\crowd_run_2160p50.mkv
 optimizing the subJobs
Added new job with id 18_22_32_3210
Created jobs for:
 I:\crowd_run_2160p50.y4m

Starting Main@18:22:41.419:
"C:\PROGRA~1\Hybrid\x265.exe" --preset veryslow --input - --input-res 3840x2160 --fps 50 --frames 500 --bitrate 4000 --colormatrix bt470bg --output "W:\TEMP\crowd_run_2160p50_18_22_32_3210_01.265"
x265 [info]: HEVC encoder version 0.9+9-8273932bc5b7
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-5.1 (Main tier)
x265 [info]: WPP streams / pool / frames         : 34 / 12 / 3
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       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-4000 kbps / 1.0 / 1
x265 [info]: tools: rect amp rd=6 lft sao-lcu sign-hide
encoded 500 frames in 1148.34s (0.44 fps), 3995.29 kb/s
x265 [info]: frame I: 2      Avg QP:37.93  kb/s: 60375.20
x265 [info]: frame P: 117    Avg QP:42.93  kb/s: 9782.56
x265 [info]: frame B: 381    Avg QP:45.05  kb/s: 1922.13
x265 [info]: global : 500    Avg QP:44.53  kb/s: 3995.28
x265 [info]: Weighted P-Frames: Y:0.9% UV:0.0%
x265 [info]: consecutive B-frames: 0.8% 0.0% 0.0% 81.5% 12.6% 5.0% 0.0% 0.0% 0.0%
finished after 00:19:10.253
Created W:\TEMP\crowd_run_2160p50_18_22_32_3210_01.265 (4.76474 MB)

Starting Main@18:41:51.689:
"C:\PROGRA~1\Hybrid\mkvmerge.exe" --ui-language en -o "W:\OUTPUT\crowd_run_2160p50.mkv" --engage no_cue_duration --engage no_cue_relative_position --global-tags "W:\TEMP\crowd_run_2160p50_18_22_32_3210__02.xml" -d 0 --default-track 0:yes --default-duration 0:5000000/100000fps --aspect-ratio-factor 0:1/1 --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "W:\TEMP\crowd_run_2160p50_18_22_32_3210_01.265"
finished after 00:00:00.334
Created W:\OUTPUT\crowd_run_2160p50.mkv (4.77354 MB)
finishedJob: 18_22_32_3210
Job 18_22_32_3210 finished!

x264

RAM  3,600,000 KB --- 3,628,000 KB

Creating jobs for 1 sources,...
 -> Creating jobs for source 1,...
 -> Generating calls for: W:\OUTPUT\crowd_run_2160p50.mkv
adding x264 calls for source: 1
createJobs for W:\OUTPUT\crowd_run_2160p50.mkv
 optimizing the subJobs
Added new job with id 18_45_29_2310
Created jobs for:
 I:\crowd_run_2160p50.y4m

Starting Main@18:45:39.134:
"C:\PROGRA~1\Hybrid\x264.exe" --preset veryslow --bitrate 16000 --profile high --level 5.2 --ref 2 --ratetol 2 --aq-mode 2 --vbv-maxrate 16000 --vbv-bufsize 300000 --non-deterministic --colormatrix undef --input-csp i420  --fps 5000000/100000 --input-res 3840x2160 --output "W:\TEMP\crowd_run_2160p50_18_45_29_2310_01.264" -
raw [info]: 3840x2160p 0:0 @ 50/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 5.2
x264 [info]: frame I:2     Avg QP:34.20  size:383077
x264 [info]: frame P:118   Avg QP:40.44  size: 89762
x264 [info]: frame B:380   Avg QP:43.48  size: 24492
x264 [info]: consecutive B-frames:  0.4%  0.0%  3.0% 69.6% 21.0%  6.0%  0.0%  0.0%  0.0%
x264 [info]: mb I  I16..4: 16.4% 75.3%  8.4%
x264 [info]: mb P  I16..4:  1.3%  7.2%  0.1%  P16..4: 39.6%  8.6%  7.2%  0.0%  0.0%    skip:35.9%
x264 [info]: mb B  I16..4:  0.0%  0.2%  0.0%  B16..8: 46.4%  3.4%  0.4%  direct: 0.6%  skip:49.0%  L0:44.7% L1:54.1% BI: 1.2%
x264 [info]: 8x8 transform intra:82.3% inter:83.3%
x264 [info]: direct mvs  spatial:97.4% temporal:2.6%
x264 [info]: coded y,uvDC,uvAC intra: 48.8% 56.2% 19.1% inter: 4.6% 4.7% 0.1%
x264 [info]: i16 v,h,dc,p: 33% 21%  8% 39%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  7%  4%  3% 12% 16% 16% 16% 14% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu:  7%  4%  1% 12% 15% 15% 16% 13% 17%
x264 [info]: i8c dc,h,v,p: 38% 19% 20% 23%
x264 [info]: Weighted P-Frames: Y:0.8% UV:0.0%
x264 [info]: ref P L0: 67.6% 12.6% 19.7%  0.1%
x264 [info]: ref B L0: 93.7%  6.3%
x264 [info]: ref B L1: 98.3%  1.7%
x264 [info]: kb/s:16531.91
encoded 500 frames, 4.49 fps, 16531.91 kb/s
finished after 00:01:51.528
Created W:\TEMP\crowd_run_2160p50_18_45_29_2310_01.264 (19.7076 MB)

Starting Main@18:47:30.676:
"C:\PROGRA~1\Hybrid\mkvmerge.exe" --ui-language en -o "W:\OUTPUT\crowd_run_2160p50.mkv" --engage no_cue_duration --engage no_cue_relative_position --global-tags "W:\TEMP\crowd_run_2160p50_18_45_29_2310__02.xml" -d 0 --default-track 0:yes --default-duration 0:50fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "W:\TEMP\crowd_run_2160p50_18_45_29_2310_01.264"
finished after 00:00:00.357
Created W:\OUTPUT\crowd_run_2160p50.mkv (19.7168 MB)
finishedJob: 18_45_29_2310
Job 18_45_29_2310 finished!

[gonca]

Willing to do it again if different settings required

[x265]

Gonca,
Thanks for running this test. I apologize but I forgot which clip it was where people preferred x265 at 1/4 the bit rate. It was In_To_Tree.

With Crowd_Run, x265 looks better at 2X the bit rate, but not at 4X. You'll see some pretty obvious macro-blocking issues with x264 at 8 Mbps.

You can download the elementary bitstreams from...
http://x265.org/in_to_tree_2160p50_16000kbps.264
http://x265.org/in_to_tree_2160p50_4000kbps.hevc
Please check my work and let me know if you spot any issues. Both clips were encoded with simply with --preset veryslow --bitrate XXXX

Even though there is obviously more detail in the x264 clip at 16 Mbps, there are some obvious issues (especially at the base of the tree in the first couple of seconds) that you don't see in the x265 bitstream. Most people preferred the x265 encode in a side by side comparison.

This clip is just an example of how H.265 has more advanced coding tools, allowing for more accurate representation of scenes in motion. No one is claiming that x265 is 4x better than x264. I just wanted to open some eyes to let people know current the state of x265, and the powerful advantages of the latest video coding standard.

[LigH.de]

Well, apart from the noise in the sky and the fine details, I would say that in_to_tree is "no big challenge" for a video codec with elaborate motion estimation and weighted temporal relations. No surprise that an even more hierarchical codec than H.264 can spare even more bitrate, being more successful at finding redundancies to remove.

The rather hard-to-predict videos, like the water surface in ducks_take_off, and the multi level parallax in crowd_run, appear more complex to me. Less redundancy to find means less bitrate to spare for both codecs, H.264 as well as H.265.

[x265]

Well, apart from the noise in the sky and the fine details, I would say that in_to_tree is "no big challenge" for a video codec with elaborate motion estimation and weighted temporal relations. No surprise that an even more hierarchical codec than H.264 can spare even more bitrate, being more successful at finding redundancies to remove.

The rather hard-to-predict videos, like the water surface in ducks_take_off, and the multi level parallax in crowd_run, appear more complex to me. Less redundancy to find means less bitrate to spare for both codecs, H.264 as well as H.265.

Well, I'm glad that we make it look easy!

Ducks Take Off (4K 50p) is definitely a challenging clip. To my eye, x265 is the clear winner at half the bit rate of x264 (4 Mbps vs 8 Mbps, or 8 Mbps vs 16 Mbps). x264 has much better detail when given 4X the bits (16 Mbps vs 4 Mbps), but it still has fine-grained macroblock noise that most people would consider an issue. x265 tends to fail more gracefully when it is bit-starved. You can still see "macroblocking" at times, but it's much more subtle and hard to detect. In general x265 does what you would expect an encoder to do in this situation; it quantizes (low-pass filters) the higher frequencies, reducing spatial detail.

[gonca]

crowd running x264 at 8000 bitrate

Hybrid: homepage
Forum: public forum
Regarding problems please read: needed infos
Donate: via PayPal
Added new job with id 18_45_29_2310
 ->disabling qaac support since 'Apple Application Support' is not installed,...
Finished initialization, finished after 1.166s

Filtering input files,..
Analysing 1 input files,...
analyzing: crowd_run_2160p50.y4m
Analyzing I:\crowd_run_2160p50.y4m with raw analyser,... 
 reading the whole input file to get the frame count,..
starting auto routines for source number: 1
added new info node (Chapter selection) to stream,..
 -> finished auto routines for source number 1.
Input is completely analysed,...
Creating jobs for 1 sources,...
 -> Creating jobs for source 1,...
 -> Generating calls for: W:\OUTPUT\crowd_run_2160p50.mkv
adding x264 calls for source: 1
createJobs for W:\OUTPUT\crowd_run_2160p50.mkv
 optimizing the subJobs
Added new job with id 16_56_06_0210
Created jobs for:
 I:\crowd_run_2160p50.y4m

Starting Main@16:56:12.836:
"C:\PROGRA~1\Hybrid\x264.exe" --bitrate 8000 --profile high --level 5.2 --ref 2 --direct auto --sync-lookahead 15 --ratetol 2 --qcomp 0.5 --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 5 --trellis 0 --weightp 1 --aq-mode 2 --vbv-maxrate 8000 --vbv-bufsize 300000 --non-deterministic --colormatrix undef --input-csp i420  --fps 5000000/100000 --input-res 3840x2160 --output "W:\TEMP\crowd_run_2160p50_16_56_06_0210_01.264" -
raw [info]: 3840x2160p 0:0 @ 50/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 5.2
x264 [info]: frame I:2     Avg QP:35.88  size:274349
x264 [info]: frame P:250   Avg QP:42.35  size: 38489
x264 [info]: frame B:248   Avg QP:46.93  size:  5698
x264 [info]: consecutive B-frames:  0.8% 99.2%  0.0%  0.0%
x264 [info]: mb I  I16..4: 23.1% 62.0% 14.9%
x264 [info]: mb P  I16..4: 15.7%  0.0%  0.1%  P16..4: 34.7%  6.4%  1.0%  0.0%  0.0%    skip:42.0%
x264 [info]: mb B  I16..4:  0.5%  0.0%  0.0%  B16..8:  6.4%  0.7%  0.0%  direct: 1.4%  skip:91.1%  L0:31.5% L1:66.2% BI: 2.3%
x264 [info]: 8x8 transform intra:2.9% inter:48.6%
x264 [info]: direct mvs  spatial:40.7% temporal:59.3%
x264 [info]: coded y,uvDC,uvAC intra: 4.4% 28.3% 6.5% inter: 1.0% 3.8% 0.0%
x264 [info]: i16 v,h,dc,p: 47% 24% 17% 12%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 17% 22%  8%  7%  7%  7%  7%  9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 16% 24%  7%  7%  7%  7%  7%  6%
x264 [info]: i8c dc,h,v,p: 82%  6% 11%  1%
x264 [info]: Weighted P-Frames: Y:0.8% UV:0.0%
x264 [info]: ref P L0: 66.7% 33.3%
x264 [info]: ref B L0: 90.6%  9.4%
x264 [info]: kb/s:9267.36
encoded 500 frames, 22.07 fps, 9267.36 kb/s
finished after 00:00:22.817
Created W:\TEMP\crowd_run_2160p50_16_56_06_0210_01.264 (11.0476 MB)

Starting Main@16:56:35.668:
"C:\PROGRA~1\Hybrid\mkvmerge.exe" --ui-language en -o "W:\OUTPUT\crowd_run_2160p50.mkv" --engage no_cue_duration --engage no_cue_relative_position --global-tags "W:\TEMP\crowd_run_2160p50_16_56_06_0210__02.xml" -d 0 --default-track 0:yes --default-duration 0:50fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "W:\TEMP\crowd_run_2160p50_16_56_06_0210_01.264"
finished after 00:00:00.395
Created W:\OUTPUT\crowd_run_2160p50.mkv (11.0565 MB)
finishedJob: 16_56_06_0210
Job 16_56_06_0210 finished!

[gonca]

ducks take off

x265

Hybrid: homepage
Forum: public forum
Regarding problems please read: needed infos
Donate: via PayPal
 ->disabling qaac support since 'Apple Application Support' is not installed,...
Finished initialization, finished after 0.967s

Filtering input files,..
Analysing 1 input files,...
analyzing: ducks_take_off_2160p50.y4m
Analyzing I:\ducks_take_off_2160p50.y4m with raw analyser,... 
 reading the whole input file to get the frame count,..
starting auto routines for source number: 1
added new info node (Chapter selection) to stream,..
 -> finished auto routines for source number 1.
Input is completely analysed,...
Creating jobs for 1 sources,...
 -> Creating jobs for source 1,...
 -> Generating calls for: W:\OUTPUT\ducks_take_off_2160p50.mkv
adding x265 calls for source: 1
createJobs for W:\OUTPUT\ducks_take_off_2160p50.mkv
 optimizing the subJobs
Added new job with id 17_17_44_5210
Created jobs for:
 I:\ducks_take_off_2160p50.y4m

Starting Main@17:17:47.987:
"C:\PROGRA~1\Hybrid\x265.exe" --preset veryslow --input - --input-res 3840x2160 --fps 50 --frames 500 --bitrate 4000 --output "W:\TEMP\ducks_take_off_2160p50_17_17_44_5210_01.265"
x265 [info]: HEVC encoder version 0.9+9-8273932bc5b7
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-5.1 (Main tier)
x265 [info]: WPP streams / pool / frames         : 34 / 12 / 3
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       : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt        : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-4000 kbps / 1.0 / 1
x265 [info]: tools: rect amp rd=6 lft sao-lcu sign-hide
encoded 500 frames in 1202.84s (0.42 fps), 4019.83 kb/s
x265 [info]: frame I: 3      Avg QP:40.89  kb/s: 35888.27
x265 [info]: frame P: 122    Avg QP:44.56  kb/s: 11919.28
x265 [info]: frame B: 375    Avg QP:45.10  kb/s: 1194.92
x265 [info]: global : 500    Avg QP:44.94  kb/s: 4019.83
x265 [info]: Weighted P-Frames: Y:12.3% UV:11.5%
x265 [info]: consecutive B-frames: 3.2% 0.8% 0.8% 85.6% 7.2% 2.4% 0.0% 0.0% 0.0%
finished after 00:20:04.747
Created W:\TEMP\ducks_take_off_2160p50_17_17_44_5210_01.265 (4.79399 MB)

Starting Main@17:37:52.744:
"C:\PROGRA~1\Hybrid\mkvmerge.exe" --ui-language en -o "W:\OUTPUT\ducks_take_off_2160p50.mkv" --engage no_cue_duration --engage no_cue_relative_position --global-tags "W:\TEMP\ducks_take_off_2160p50_17_17_44_5210__02.xml" -d 0 --default-track 0:yes --default-duration 0:5000000/100000fps --aspect-ratio-factor 0:1/1 --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "W:\TEMP\ducks_take_off_2160p50_17_17_44_5210_01.265"
finished after 00:00:00.280
Created W:\OUTPUT\ducks_take_off_2160p50.mkv (4.80282 MB)
finishedJob: 17_17_44_5210
Job 17_17_44_5210 finished!

x264

Creating jobs for 1 sources,...
 -> Creating jobs for source 1,...
 -> Generating calls for: W:\OUTPUT\ducks_take_off_2160p50.mkv
adding x264 calls for source: 1
createJobs for W:\OUTPUT\ducks_take_off_2160p50.mkv
 optimizing the subJobs
Added new job with id 17_40_15_3310
Created jobs for:
 I:\ducks_take_off_2160p50.y4m

Starting Main@17:40:20.549:
"C:\PROGRA~1\Hybrid\x264.exe" --bitrate 8000 --profile high --level 5.2 --ref 2 --direct auto --sync-lookahead 15 --ratetol 2 --qcomp 0.5 --partitions i4x4,p8x8,b8x8 --no-fast-pskip --subme 5 --trellis 0 --weightp 1 --aq-mode 2 --vbv-maxrate 8000 --vbv-bufsize 300000 --non-deterministic --colormatrix undef --input-csp i420  --fps 5000000/100000 --input-res 3840x2160 --output "W:\TEMP\ducks_take_off_2160p50_17_40_15_3310_01.264" -
raw [info]: 3840x2160p 0:0 @ 50/1 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High, level 5.2
x264 [info]: frame I:3     Avg QP:40.84  size:154484
x264 [info]: frame P:326   Avg QP:46.98  size: 32183
x264 [info]: frame B:171   Avg QP:48.01  size:  1847
x264 [info]: consecutive B-frames: 31.6% 68.4%  0.0%  0.0%
x264 [info]: mb I  I16..4: 16.6% 82.2%  1.2%
x264 [info]: mb P  I16..4: 26.5%  0.0%  0.0%  P16..4: 30.5%  3.9%  0.3%  0.0%  0.0%    skip:38.7%
x264 [info]: mb B  I16..4:  0.1%  0.0%  0.0%  B16..8:  0.7%  0.1%  0.0%  direct: 1.8%  skip:97.4%  L0:24.1% L1:59.0% BI:16.9%
x264 [info]: 8x8 transform intra:2.7% inter:74.7%
x264 [info]: direct mvs  spatial:94.7% temporal:5.3%
x264 [info]: coded y,uvDC,uvAC intra: 1.9% 33.2% 8.1% inter: 0.5% 6.1% 0.0%
x264 [info]: i16 v,h,dc,p: 24% 53% 13% 10%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu:  3% 60% 12%  2%  3%  1%  9%  1%  9%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu:  5% 45% 24%  3%  4%  2%  9%  1%  6%
x264 [info]: i8c dc,h,v,p: 85% 14%  1%  0%
x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x264 [info]: ref P L0: 55.0% 45.0%
x264 [info]: ref B L0: 87.9% 12.1%
x264 [info]: kb/s:9016.80
encoded 500 frames, 20.59 fps, 9016.80 kb/s
finished after 00:00:24.434
Created W:\TEMP\ducks_take_off_2160p50_17_40_15_3310_01.264 (10.7489 MB)

Starting Main@17:40:44.998:
"C:\PROGRA~1\Hybrid\mkvmerge.exe" --ui-language en -o "W:\OUTPUT\ducks_take_off_2160p50.mkv" --engage no_cue_duration --engage no_cue_relative_position --global-tags "W:\TEMP\ducks_take_off_2160p50_17_40_15_3310__02.xml" -d 0 --default-track 0:yes --default-duration 0:50fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles "W:\TEMP\ducks_take_off_2160p50_17_40_15_3310_01.264"
finished after 00:00:00.337
Created W:\OUTPUT\ducks_take_off_2160p50.mkv (10.7579 MB)
finishedJob: 17_40_15_3310
Job 17_40_15_3310 finished!

[LigH.de]

A Phenom-II X4 is probably not the best CPU to run such extensive tests; even with just a 1080p resolution, ~0.1 fps is a challenge for patience. So I won't even try 4K UHD with such slow presets. Anything below Bulldozer class makes AMD CPUs a disadvantage.

Still, there are interesting results already for the 1080p HD tests:

x265 --crf 30 --preset veryslow

crowd_run: 4330 kbps @ 0.07 fps
ducks_take_off: 3881 kbps @ 0.08 fps
in_to_tree: 1312 kbps @ 0.12 fps

As predicted: The easier a good matching motion vector can be found, the faster the encoding is, and the less bitrate is required for the same rate factor (quality-loss threshold).

A "same bitrate" 2-pass encode with x264 reports a rate factor around 33-34; a "double bitrate" encode is close to a rate factor 29-30. Of course, I am not sure if "rate factor" has a comparable meaning between x264 and x265. But subjectively, I would agree that a similar rate factor means a similar level of annoyance regarding compression artefacts. The bad result of x264 for in_to_tree is probably due to the disregard of the sky in relation to the trees (it seems to heavily underestimate the lack of details in it).

The codecs drop quality in different areas; x264 rather starts fraying (or even adding wrong) edges, x265 rather flattens small detail structures. Especially for "traditional cartoons", x265 will certainly become a favourite.

I'm starting to upload some clips to MediaFire, available in ~15 min... — Done.

[LigH.de]

What does x265 need all the RAM for?

It can't be just the frame buffer; x265 seems to allocate a lot more, possibly about 250 times the size a raw frame needs (as if it would allocate for all frames of a whole default GOP). Just an example based on my experiences with 4K UHD video:

3840×2160 pixels × 12 Bit (YUV 4:2:0) = 12150 KB per 4K UHD frame; assuming 250 Frames, you get ~2.9 GB, close to the allocated amount of RAM.

But when I add the parameter --keyint 100 or --keyint 50 to reduce the GOP size, x265 still allocates more than 2 GB RAM (which makes encoding of UHD video on 32-bit Windows impossible).

Something else must require a lot more RAM than just the necessary frame buffer – which should only need to keep the reference frames: The last I frame and some previous P- and possibly B-frames in the referencable range; so it should even need much less RAM for faster presets. At least the opposite extreme appears to be true: Encoding 1080p FullHD video fails with preset "placebo" on 32-bit Windows because it just exceeds the 2 GB process memory; faster presets barely pass.

[Stears555]

Well, apart from the noise in the sky and the fine details, I would say that in_to_tree is "no big challenge" for a video codec with elaborate motion estimation and weighted temporal relations. No surprise that an even more hierarchical codec than H.264 can spare even more bitrate, being more successful at finding redundancies to remove.

The rather hard-to-predict videos, like the water surface in ducks_take_off, and the multi level parallax in crowd_run, appear more complex to me. Less redundancy to find means less bitrate to spare for both codecs, H.264 as well as H.265.

Well, I'm glad that we make it look easy!

Ducks Take Off (4K 50p) is definitely a challenging clip. To my eye, x265 is the clear winner at half the bit rate of x264 (4 Mbps vs 8 Mbps, or 8 Mbps vs 16 Mbps). x264 has much better detail when given 4X the bits (16 Mbps vs 4 Mbps), but it still has fine-grained macroblock noise that most people would consider an issue. x265 tends to fail more gracefully when it is bit-starved. You can still see "macroblocking" at times, but it's much more subtle and hard to detect. In general x265 does what you would expect an encoder to do in this situation; it quantizes (low-pass filters) the higher frequencies, reducing spatial detail.

Why doesn't x265 2-pass mode?

[gonca]

LigH.de
If you look at post 191 you will see that x265 used nearly 7 GB of RAM on very slow preset
32 bit OS has no hope

[El Heggunte]

32 bit OS has no hope

Let's hope the MCW people doesn't see that as a good excuse for inefficient coding

[Stears555]

Well, apart from the noise in the sky and the fine details, I would say that in_to_tree is "no big challenge" for a video codec with elaborate motion estimation and weighted temporal relations. No surprise that an even more hierarchical codec than H.264 can spare even more bitrate, being more successful at finding redundancies to remove.

The rather hard-to-predict videos, like the water surface in ducks_take_off, and the multi level parallax in crowd_run, appear more complex to me. Less redundancy to find means less bitrate to spare for both codecs, H.264 as well as H.265.

Well, I'm glad that we make it look easy!

Ducks Take Off (4K 50p) is definitely a challenging clip. To my eye, x265 is the clear winner at half the bit rate of x264 (4 Mbps vs 8 Mbps, or 8 Mbps vs 16 Mbps). x264 has much better detail when given 4X the bits (16 Mbps vs 4 Mbps), but it still has fine-grained macroblock noise that most people would consider an issue. x265 tends to fail more gracefully when it is bit-starved. You can still see "macroblocking" at times, but it's much more subtle and hard to detect. In general x265 does what you would expect an encoder to do in this situation; it quantizes (low-pass filters) the higher frequencies, reducing spatial detail.

Why don't you use GPU acceleration for HEVC encoding?

You promised a fantastic OPENCL Hevc encoder....
Read about it: http://www.multicorewareinc.com/video.html

[gonca]

Let's hope the MCW people doesn't see that as a good excuse for inefficient coding

They would have to cut ram usage in half for a 32 bit OS. This might create a significant "speed" hit. I am assuming that the coding isn't so inefficient as to require twice as much ram as it should.

[LigH.de]

Why doesn't x265 2-pass mode?

Because someone has to implement it. Soon™.

Why don't you use GPU acceleration for HEVC encoding?

Which GPU could possibly accellerate it at all? And which encoder would those without it have to use?

LigH.de
If you look at post 191 you will see that x265 used nearly 7 GB of RAM on very slow preset
32 bit OS has no hope

I tried 8K UHD once and it tried to allocate ~12 GB. It did not crash on Windows 7 64-bit with 8 GB RAM, but started using the swap file for the missing 4 GB. What a role model of the difference between effective and efficient.

[Stears555]

Why doesn't x265 2-pass mode?

Because someone has to implement it. Soon™.

Why don't you use GPU acceleration for HEVC encoding?

Which GPU could possibly accellerate it at all? And which encoder would those without it have to use?

They promised a fantastic OPENCL Hevc encoder....
Read about it: http://www.multicorewareinc.com/video.html

[LigH.de]

Don't build the balcony before the basement.

[Stears555]

Don't build the balcony before the basement.

Read their other promise here: http://www.prweb.com/releases/2014/04/prweb11739806.htm

[LigH.de]

So...

Link #1: Multicoreware announced an OpenCL accelerated HEVC (H.265) Decoder, and an OpenCL accelerated AVC (H.264) encoder. But I don't read about an OpenCL accelerated HEVC (H.265) encoder there.

Still, the question remains: Is it certain that OpenCL is able to accelerate HEVC encoding? I remember that GPU based acceleration for AVC encoding does exist, but every such encoder yet (Nvidia CUDA, intel QuickSync, AMD Stream) was only able to produce very limited complexity, thus rather bad quality.

But why already limit the range of users? Almost everyone will have a CPU suitable to run x265. Not quite everyone will have a potent OpenCL capable GPU, though.

Link #2: Multicoreware announced the development of neural network based video processing, and also mentions developing HEVC encoding. But I don't read there that DLNNs are useful for HEVC encoding.

[Selur]

@LigH: regarding GPU accelerated AVC encoding, only encoder that isn't an on chip solution I know of is the one from mainconcept
regarding neural networks and HEVC encoding: Intra Frame Luma Prediction using Neural Networks in HEVC: https://dspace.uta.edu/bitstream/handle/10106/11804/Kumar_uta_2502M_12203.pdf, but clue if Multicoreware is looking into that.

Almost everyone will have a CPU suitable to run x265. Not quite everyone will have a potent OpenCL capable GPU, though.

don't agree with that, when looking at the mobile&tablet market you will probably have more luck finding a fast gpu than a fast cpu