I'm going to take a break from x265 for a while. Every new build gets slower and slower so there is no need for me to keep banging my head against the wall, hoping that someone has created a build that will encode HEVC faster than 5 fps. I'll check back in a few months to see if MCW has decided to concentrate on making the encoder faster. Besides, I should be outside enjoying the nice weather instead of sitting at the computer, waiting for another heart attack.
+ Reply to Thread
Results 1,501 to 1,530 of 2190
current version build with MinGW
jb_alvarado's media-autobuild_suite is going to work well again with MSYS2-64; x265 already builds with GCC 4.9.0; so there are experimental builds of the 4 EXE flavours. Yet, a few issues have to be fixed still...
And because there was a stable-merge again, version 1.0+21-8963bc3aa2e1 with the usual MSYS (GCC 4.8.2).
Last edited by LigH.de; 7th May 2014 at 03:38.
does anybody knows how cmake gets his version info for x265 from hg? When I use the TortoiseHg installer pack to clone, I can compile x265 normal under windows with msys2/mingw-w64 and it gets also the correct version. But when I try to use the build in mercurial hg tool from msys2 it don't get the version number and cmake stops with errors.
When I use the TortoiseHg installer pack to clone, I can compile x265 normal under windows with msys2/mingw-w64 and it gets also the correct version. But when I try to use the build in mercurial hg tool from msys2 it don't get the version number and cmake stops with errors.
Also, I have no experience with TortoiseHg. The x265 wiki still must be read with some tons of salt (unfortunately).
Hello El Heggunte,
thanks for your answer! This doesn't help. I don't work with the windows path variable, I work with my msys profile, and there is the all in the path I think. When not than I think mercurial can not clone and cmake can not build.
Is strange, I even don't install TortoiseHg, I only unpack the msi file, put the path in my profile and it work. I need to ask the developer from msys2.
I was working before with msys1 and I think the new version is way smarter, so I don't want to go back.
commit 7d11f60 is here : —/
OK, time to join in again.
being in possession of content with the usual amount of artifacts, ie, (tv sources) -- won't help with these kinds of upgrade efficiencies. but i'll have to test for myself and see if there really is any difference or penalty using an older x265 build once the x265 team update their portal with the latest build, since they don't update that area often. i'm at their mercy since i don't know how to compile for xp. and before you ask.. no, i don't go to sharing sites like mediafire. my pc is not equipt to handle (block) their ads.
commit d78f38b707ba "for the rest of the world"
For those who don't like MediaFire&Co I compiled and attached the lates (MinGW 32/64bit; 8bit/16bit) x265 versions.
Well, among many other file hosters, MediaFire is rather fair, IMHO; not too many ads, not too hard limits, quite compatible (even Opera 12 can handle it and block flash ads without disabling the download).
From what I understand, it doesn't make all presets faster but just speeds up the medium preset to pretty much do away with the need for other presets unless you are a glutton for punishment with super slow encoding speeds. The faster presets are no faster than before.
Still a long way off if expected to replace x264. Like Ligh stated though, time to clean out all older x265 folders.
We have sped up the ultrafast preset by about 10 to 30% (bigger
benefit at higher bit rates). There is a very small impact on encoding
efficiency, but you can always increase efficiency by using a slower
(higher quality) preset. We've also sped up the superfast, veryfast
and faster presets in a similar way.
Last edited by DarrellS; 4th Jun 2014 at 08:33.
Practical encoding speed will depend on many factors. If the bottleneck is reading the huge uncompressed source file from a slow harddisk (or an elaborately filtered AviSynth script via avs4x265 pipe), then faster calculations in x265 won't speed up anything. And supported CPU instructions may have some impact as well, even when the source is read fast.
I encoded a 1080p clip at 15 fps so there is some improvement there but using the medium preset, I only got 3.2 fps. Also, I add --crt 18 to my presets and using the external encoder in Virtualdub, I get an anonymous pipe error on the medium preset and have to remove the --crt 18 from my command argument to get it to encode. The ultrafast preset ends up with almost double the bitrate as the medium preset.
There is no command line option "--crt". Maybe you mean "--crf".
But it also depends on the position where you put options into a command line. At the wrong position, it may split an option from its argument, and the command line parsing gets confused.
Whoa, I screwed that up pretty good. My first preset was correct but somehow I managed to hit the t key instead of f key, then copied and pasted to all my other encoders.
Thanks for that. I doubt that I would've figured it out on my own. I need to get better reading glasses I guess.
EDIT: Looks like I used -q 18 on ultrafast.
Last edited by DarrellS; 4th Jun 2014 at 17:41.
I guess I need to clean out everything and start over cause I can't get anything to work now. Gets to the last frame and crashes. None of my x265 presets work. I must've used an older encoder earlier today instead of the new one.
Crashing during the after-encode summary in "ultrafast" and "superfast" presets is already a known issue to me. I notified the developers, they are about to fix it. A next release should work well again...
Uh, nice. It became tiny, doesn't include an x265 anymore. No changelog though, probably still does the same (feeding raw YUV and adding required parameters). Maybe does it include now suggested additions from the avs4x264 thread in the doom9 forum (which seem to got lost there, but I got an email notification about the disappeared reply)? It seems to support High Bit Depth script output, according to what I understand from the C sources.
Ah, it is explained from here on.
P.S.: x265 1.1+35-495874699b0d on MediaFire and below.
Another stable merge + one more useful patch. Presets ultrafast and superfast should not crash anymore during the summary.
Last edited by LigH.de; 5th Jun 2014 at 03:02.
I can confirm that the crash problem is fixed in x265_1.1+35-495874699b0d but the encode speeds are much lower (10.39 fps) than yesterday and lower than the old version that I still have.
I tried Fllear's build and encoded 1080p at 16.26 fps.
VideoEnc: encoded 432 frames in 26.57s (16.26 fps), 483.14 kb/s
Something is wrong with 1.1+45. Every build that I tried would only encode 1920x1080 at 4.3 fps.
"C:\PROGRA~1\Hybrid\x265.exe" --tune ssim --preset slower --input - --input-res 1920x1080 --fps 50 --frames 19 --max-merge 5 --no-strong-intra-smoothing --weightb --b-adapt 1 --bitrate 2000 --psy-rd 0.5 --aq-mode 1 --no-cutree --sao-lcu-bounds 1 --colormatrix bt709 --output "C:\Users\PARADO~1\AppData\Local\Temp\x265_11_11_3 4_6710_01.265"
x265 [info]: HEVC encoder version 1.1+45-e5656f1e1904
x265 [info]: build info [Windows][ICC 1400][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x265 [info]: WPP streams / pool / frames : 17 / 2 / 1
x265 [info]: Main profile, Level-4.1 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 2 / 2
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 5
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 30 / 8 / 1
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 1 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-2000 kbps / 1.0 / 0
x265 [info]: tools: rect amp rd=6 psy-rd=0.5 lft sao-lcu signhide
encoded 19 frames in 95.49s (0.20 fps), 2098.84 kb/s
x265 [info]: frame I: 1 Avg QP:44.83 kb/s: 5971.60
x265 [info]: frame P: 9 Avg QP:42.19 kb/s: 3493.07
x265 [info]: frame B: 9 Avg QP:44.60 kb/s: 274.31
x265 [info]: global : 19 Avg QP:43.47 kb/s: 2098.84
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 10.0% 90.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%
finished after 00:01:35.721
- - - - -
Strip from the trees show that the encoder does not produce image correction with the next frame - stupid duplicates / not refer to changes (not subtracts).
My suspicions seem to come true:
> theory 1
> theory 2
Also > DivX
Last edited by Gravitator; 10th Jun 2014 at 23:15.
@Graviator: don't use psy-rd, it's known to produce artifacts