[HEVC] x265.EXE: mingw builds

[easyfab]

new test build for fun
x265 version 0.5+155-450947d76251
build info [Windows][GCC 4.8.2][64 bit] 8bpp with -march=corei7-avx
If you have a corei7 tell me if it's faster
For me on a small test mingw 64 corei7-avx is 8.28 fps vs vs10 build 7.77 fps

[Tommy Carrot]

The x265 thread seems more active here, and there is more discussion about the technical details and stuff that interests me. The doom9 thread is more about how to use the encoder. And i don't even remember my password there, it's been ages since i stopped posting there. I'm surprised you still remember me.

My memories are from ages ago when I stopped visiting. We never spoke but I remember you for the x264vfw and Snow codec guide you wrote or partly wrote. Welcome to Videohelp, we hope your stay is a pleasant one.

Thank you.

About x265, I'd like to join the fun but I've been unable to get x265 to recognize my input so I've only been able to test DivxHEVC so far and its quality is disappointing.

Is huffyuv a codec that outputs adequate YUV output because x265 still encoded garbage when I tried it.

x264 only accepts raw yuv input, it cannot process compressed stuff. If you have avisynth installed, avs2yuv is fairly simple to use with it.

avs2yuv input.avs -o -|x265 --y4m [--options] -o output.hevc -

[Mephesto]

--y4m unrecognized option.
My script: avs2yuv ng2.avs -o -|x265 --y4m --input-res 320x240 --fps 60 --frames 2334 -o ng2.hevc -

[easyfab]

And with space between - | x265

[Mephesto]

Same error.

[Tommy Carrot]

I suspect you're using an older build. Take a fairly new build from x265.cc (the latest doesn't work for me). And the 'input-res' and 'fps' options are unnecessary with y4m input.

[LigH.de]

Is huffyuv a codec that outputs adequate YUV output because x265 still encoded garbage when I tried it.

The original Huffyuv codec by BenRG did not support planar YUV 4:2:0 (YV12 / i420). Only the ffmpeg/ffdshow variant supports that.

[Mephesto]

Build I was using was dated 10/25. I'm using the latest x264.cc and besides the --y4m working I can tell it actually works. I'm getting 20 fps and the bitrate is 20 kiloBYTES per second. That's what I'm talkin about!
Before I got 0.5 fps and 22 Mbps and wasted over an hour waiting for it to finish just to find out I encoded garbage which was why the bitrate was so damn high for 240p. Jeez.

Thanks Tommy, I'll post my results afterwards.

EDIT: So I did a test on a 320x240 platformer video. x264's worst frame was better quality than x265's best frame. Not good. I'm guessing I need to use 16 refs like I normally do with x264 on this kind of video and all other options specifically tweaked for this.

Good news is that it is noticeably better than DivxHEVC. I'll do a test with a photographic video now which DivxHEVC fell behind x264 by a margin.

[Selur]

HEVC encoder version 0.5+157-8f71fba52d55
still crashing on my system

[x265]

HEVC encoder version 0.5+157-8f71fba52d55
still crashing on my system

There was an issue in the latest code in the development branch dealing with file input. It seems to be fixed now in version 0.5+181-60f78cbfacc8.

Tom

[vhelp]

regarding 0.5+181-60f78cbfacc8, GCC 4.8.2][32 bit] 16bpp build
windows xp home sp2, amd dual core cpu 2g ram
MMX2 SSE SSE2Slow SlowCTZ

did i miss something in these posts regarding the 16bpp encodes and playback method ?

well, they don't play. i thought we were suppose to use the 8bpp versions. but i wanted to try the 16bpp version to see if it would work on my pc (because the few older versions i tried over the past month had crahsed and i thought it was due to my pc) but i wanted to try one more time. the encoder works, not any faster, (that i could determine) but don't play..mostly green blocks.

so, i should stay with the 8bpp version, correct ?

[deadrats]

regarding 0.5+181-60f78cbfacc8, GCC 4.8.2][32 bit] 16bpp build
windows xp home sp2, amd dual core cpu 2g ram
MMX2 SSE SSE2Slow SlowCTZ

did i miss something in these posts regarding the 16bpp encodes and playback method ?

well, they don't play. i thought we were suppose to use the 8bpp versions. but i wanted to try the 16bpp version to see if it would work on my pc (because the few older versions i tried over the past month had crahsed and i thought it was due to my pc) but i wanted to try one more time. the encoder works, not any faster, (that i could determine) but don't play..mostly green blocks.

so, i should stay with the 8bpp version, correct ?

the test encodes i did with 16bit internal precision played back fine with mpc/mpc-hd + lav filters and pot player, with the exception of one file that showed minor artifacts around some of the edges of some of the frames of the video, but over-all i didn't have any major problems.

[x265]

regarding 0.5+181-60f78cbfacc8, GCC 4.8.2][32 bit] 16bpp build
windows xp home sp2, amd dual core cpu 2g ram
MMX2 SSE SSE2Slow SlowCTZ

did i miss something in these posts regarding the 16bpp encodes and playback method ?

well, they don't play. i thought we were suppose to use the 8bpp versions. but i wanted to try the 16bpp version to see if it would work on my pc (because the few older versions i tried over the past month had crahsed and i thought it was due to my pc) but i wanted to try one more time. the encoder works, not any faster, (that i could determine) but don't play..mostly green blocks.

so, i should stay with the 8bpp version, correct ?

Correct. We'll let you know when support for 16 bpp is stable.

Tom

[Mephesto]

What's this bpp terminology now? I assume it doesn't stand for bits per pixel.

EDIT: I did a test on a music video and x265 is ahead of DivxHEVC but still lagging behind x264. Many frames marginally better, a couple staggeringly worse so it easily brings down the average SSIM.

First chart is the music video, second is the video game capture. Damn, the power of mb-tree...

[Selur]

How I understood it so far:
bpp should be bit per pixel for and define the internal calculation precision, all x265 output atm. should be:
a. 8bpp output precision
b. Yv12 coded
higher output precision (10 and 12bit) and other color spaces are not supported atm.
That said, if the internal 16bpp routines do not work properly,....

[Selur]

There was an issue in the latest code in the development branch dealing with file input. It seems to be fixed now in version 0.5+181-60f78cbfacc8.

64bit 8bpp "rev 0.5+182-93cccbe49a93 (UTC 2:29:42 AM)" from x264.cc is still crashing
here's command line I used for testing:

mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420 -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi" | x265 --input - --input-res 640x352 --fps 25 --frames 429 --output "H:\Output\test_08_48_19_2810_01.265"

[LigH.de]

In case someone is interested in speed-testing HEVC decoders:

I just encoded a 1 minute snippet from "Tears of Steel" using x265 with CRF 12, but still a slower preset to ensure a high complexity to stress decoders. It has an average of ~31.3 Mbps video bitrate. Peaks are around 100 Mbps (if I can use the bits-per-frame log as reliable presentation base).

tos_60s_hevc.mp4 on MediaFire (224 MB)

[Selur]

Got two questions:

1. What does CDR stand for?
   
   I know HEVC introduced Clean Random Access (CRA) frames, which are basically what has been called open Group-of-Pictures (GOP) intra pictures.
   More detailed thoughts can be found here.
   
   -> I assume CDR is the same as CRA, but what does the acronym stand for exactly?
2. What does '--rc-lookahead' do?
   the help states:
   "--rc-lookahead Number of frames for frame-type lookahead (determines encoder latency)"
   Is this, like in x264, mainly some caching of frames to allow better threading? (thus higher values will increase the latency, but help threading efficiency?)

[Selur]

rev 0.5+187-85002898f5b4 (UTC 12:04:27 PM) seems to be working again

[LigH.de]

The "rc" in --rc-lookahead is probably related to "rate control"; for example, knowing early where a scene change / transition / blackout will be, helps regulating the bitrate (taking soon coming bigger I-frames or small P-/B-frames into account for the bitrate distribution of the current frame).
__

Apropos:

Coming soon™ (probably) — VBV bitrate regulations. At least a source patch was offered in the developer mailinglist.

[LigH.de]

Please note:

As mentioned by Steve Borho, the new Adaptive Quantization option (--aq-mode 1) may require full RDO analysis (--rd 2) in current versions; all presets faster than "slower" use a limited RDO analysis level (--rd {<2}), though. This will probably lead to visible artefacts.

[Selur]

"As mentioned by Steve Borho, ... " -> where? (neither the command line help nor the evaluators's guide state that)

[LigH.de]

In the developer mailinglist. I just reported this issue there, and he quickly replied with this suspicion...

[Selur]

okay, found it:

If 'slower' gives clean results, then the --rd setting is likely the determining factor. It's possible that AQ does not deal properly with non-RDO quant. It is an unfinished feature.

source: https://mailman.videolan.org/pipermail/x265-devel/2013-November/002156.html
(if his suspicion that is the case it's probably a bug, since aq in general should not require rdo)

[Gomorrite]

I wanted to join the fun of x265 encoding, but I'm not having any success. I just seem to be encoding garbage (funny moving color stripes is the result of my encodes). Decoding with MPC-HC+Strongene decoder seems to work because I could play some x265 encodes that were uploaded here. I tried different builds and different commands and presets, first with avs4x265, then directly with a y4m file... always the same garbage.

[El Heggunte]

^ @ Gomorrite: unless you share the exact command-line options you have tried, it's improbable anyone here will be able to help you.

[mindwin]

Gomorrite

avs2yuv input.avs -o - | x265 --y4m [--options] -o output.hevc -

Works well.
MPC even playback raw .hevc files.

[Gomorrite]

The commands mindwin just mentioned (without any option) result in this. I got a similar result with other sources and same result with other x265 builds. I also tried adding "--input-res 628x514 --fps 25".

[El Heggunte]

...... I also tried adding "--input-res 628x514 --fps 25".

628 is not divisible by 8.
514 is not divisible by 8.
So you should use Avisynth for cropping or/and adding borders

Apparently, and different from x264, x265
(AND/OR some/all of the decoders currently available)
still cannot handle uncommon frame dimensions properly

[x265.cc]

new test build for fun
x265 version 0.5+155-450947d76251
build info [Windows][GCC 4.8.2][64 bit] 8bpp with -march=corei7-avx
If you have a corei7 tell me if it's faster
For me on a small test mingw 64 corei7-avx is 8.28 fps vs vs10 build 7.77 fps

Comparing a build with the newest gcc vs a old vc, is not a good idea.

Your GCC build vs the buildbot VC12 x86_64 build (same rev) in my test:

x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: HEVC encoder version 0.5+155-450947d76251
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: Main profile, Level-2 (Main tier)
x265 [info]: WPP streams / pool / frames : 5 / 4 / 1
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 2 / 2
x265 [info]: ME / range / subpel / merge : star / 60 / 5 / 4
x265 [info]: Keyframe min / max : 250 / 250
x265 [info]: Rate Control : CQP-32
x265 [info]: Lookahead / bframes / badapt : 20 / 5 / 2
x265 [info]: tools: rect amp rd=2 ref=3 lft sao-lcu sign-hide
x265 [info]: frame I: 2 PSNR Mean: Y:41.052 U:43.046 V:44.500
x265 [info]: frame P: 106 PSNR Mean: Y:37.743 U:42.269 V:44.053
x265 [info]: frame B: 192 PSNR Mean: Y:37.829 U:42.308 V:44.083
x265 [info]: global : 300 PSNR Mean: Y:37.820 U:42.299 V:44.075

encoded 300 frames in 27.99s (10.72 fps), 27.58 kb/s, Global PSNR: 39.162

x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: HEVC encoder version 0.5+155-450947d76251
x265 [info]: build info [Windows][MSVC 1800][64 bit] 8bpp
x265 [info]: Main profile, Level-2 (Main tier)
x265 [info]: WPP streams / pool / frames : 5 / 4 / 1
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 2 / 2
x265 [info]: ME / range / subpel / merge : star / 60 / 5 / 4
x265 [info]: Keyframe min / max : 250 / 250
x265 [info]: Rate Control : CQP-32
x265 [info]: Lookahead / bframes / badapt : 20 / 5 / 2
x265 [info]: tools: rect amp rd=2 ref=3 lft sao-lcu sign-hide
x265 [info]: frame I: 2 PSNR Mean: Y:41.052 U:43.046 V:44.500
x265 [info]: frame P: 106 PSNR Mean: Y:37.743 U:42.269 V:44.053
x265 [info]: frame B: 192 PSNR Mean: Y:37.829 U:42.308 V:44.083
x265 [info]: global : 300 PSNR Mean: Y:37.820 U:42.299 V:44.075

encoded 300 frames in 27.97s (10.73 fps), 27.58 kb/s, Global PSNR: 39.162

=> Exactly the same speed, but the vc build runs also on non avx capable cpus

(Tested on Intel Core i7-3517U)