[HEVC] x265.EXE: mingw builds

[gothicdoggy]

isnt x265 still in beta ..tho I havnt seen any official encoder ..to the public with this codec yet ...I don't think it supports 8k yet maybe 2k and divx 265 is still beta I tink ...I also have 1 queston that I need help that's y I sighned up ... hybrid encoder crashes my encode at 16% well encoding x265 its really bothering me cuz my speed goes quite fast at 20 fps ..with the ''faster'' preset and reference frames of 3 and the trellis setting ..my bad now my encode is going at 23.17 fps

[Gravitator]

EDIT: I'll try to encode just one frame and see how it goes. I believe that is one of the goals, to use HEVC as a graphics compression. The frame that you uploaded is 2,096 kbs. I opened the file and saved as a .png image that was 34,027 kbs. That is a huge difference in file size.

HEVC vs JPEG? We know that the price of decoder $2; encoder how much? (or he walks in the price)
Why not overpay $2 for the ability to save in the new format

[gothicdoggy]

**** it says crashed helper send out a error qprocesss:: crashed lol

[Gravitator]

**** it says crashed

This is called the testing! let the developer sample and settings to be able to improve the product.

[gothicdoggy]

how do I get it to work im trying to encode a video ts so I can delete the original

[LigH.de]

how do I get it to work im trying to encode a video ts so I can delete the original

Don't do that. x265 is not yet final. You will certainly not yet produce a copy "for archival". Use x264 for an AVC copy instead, this encoder is reliable, and the format is established for years.
__

I can't confirm your issues with large video dimensions. Just tested simple 4K samples with 3840x2160 pixels as Y4M, raw YUV, and via avs4x265 v0.2 using v0.8+131 Win64 GCC: No crash, no empty result, all decodable.

Y4M / YUV files were created with avs4yuv 0.24bm2.

Trying again with 8K samples.
__

8K Y4M: unable to open input file
8K YUV: encodes... but seems to use so much RAM (11 GB) that it uses the swap file for each GOP.
8K AVS: same as YUV

[gothicdoggy]

sooo so r u saying x265 is not good looking on picture quality yet?? is that wut u mean ..I wonderd that because I tried the highest setting before ..n my video still didn't look as good as the orginal ....ur right x265 isn't ready then quality sux still then I guess ...I will use x264 then thanx u also wen I use x264 at medium settings the picture quality looks good like the original but x265 doesn't by the way with the 265 I used mp4 conatainer in hybrid wen I tried it and mediacoder can anyone else comfirm that 265 doesn't look as good as x264 yet? then I can no for sure to use x264 better

[LigH.de]

I don't say that the quality is not yet good. With a bitrate high enough / a rate factor small enough, x265 can probably already ensure "visually transparent encoding" (means, you won't tell apart original and copy if you don't magnify the image).

If you are lucky and catch a bug-free build. There are currently still so many changes that bugs are fixed as often as features are added and code is optimized.

And why already wasting a multiple of the time x264 requires with a not yet certainly correct as well as perfectly optimized encoder? Shouldn't we save energy in these days of climate changes?

[gothicdoggy]

well I tried hybrid encoder with x264 and x265 they both give the same error well encoding so I don't no whats wrng

[Selur]

I see no reason for HEVC to be limited to 8192x4320, afaik. at least the standard doesn't mention such a restriction.
-> There should be no reason (other than enforced interface restrictions) why HEVC encoders couldn't support way higher resolutions.

Cu Selur

[Selur]

well I tried hybrid encoder with x264 and x265 they both give the same error well encoding so I don't no whats wrng

If you report it properly, inside the Hybrid-thread, I will look at it. (properly = read and follow http://www.selur.de/support)

[LigH.de]

I see no reason for HEVC to be limited ...

Apart from memory consumption. 8 GB RAM are not enough for x265 to encode 8K resolutions efficiently. So forget 32-bit versions, it exceeds 2 GB RAM for 4K resolutions already (almost 3 GB Working Set).

[Selur]

Sure hardware restrictions, but there is no restriction inside the encoder design.

[Gravitator]

well I tried hybrid encoder with x264 and x265 they both give the same error well encoding so I don't no whats wrng

Try replacing assemblies x264 http://tmod.nmm-hd.org/x264/
Prompt #110 http://forum.selur.de/topic218-h265x265-p5.html helped me

[Sergio29]

[QUOTE=El Heggunte;2308898]

1) it seems there is a bug in the Y4M output of avs2yuv, regarding very-high frame dimensions
(the colors look incorrect or something)

2) this time, tested raw input (i.e., no y4m) with x265, BUT the actual encoding never starts --- and the final result is a zero-byte file

Its because x265 defines a min/max value for the frame size :


#define MIN_FRAME_WIDTH 64
#define MAX_FRAME_WIDTH 8192
#define MIN_FRAME_HEIGHT 64
#define MAX_FRAME_HEIGHT 4320
#define MIN_FRAME_RATE 1
#define MAX_FRAME_RATE 300

[Selur]

Did I miss something, the resolutions El Heggunte used were all inside these boundaries. So it seems unlikely that the boundaries are the problem.

[LigH.de]

Raw YUV input works, but Y4M input is misdetected. Is there anything wrong with this Y4M header?

4KTest.y4m:

YUV4MPEG2 W3840 H2160 F25:1 Ip A0:0 C420mpeg2
FRAME

8KTest.y4m:

YUV4MPEG2 W7680 H4320 F25:1 Ip A0:0 C420mpeg2
FRAME

They look the same to me. Still, trying to read 8KTest.y4m as input returns an error message immediately.

[Selur]

Is there anything wrong with this Y4M header?

no, header looks fine.
Might be a bug in x265 (assuming the unknown error message comes form x265)

[DarrellS]

It's definitely a memory issue. I can encode one 7680x4320 frame at .245 fps but if I feed the encoder two frames and change frame rate to 25 fps then it runs out of memory and fails.

[LigH.de]

Did I already mention that you should forget about 32-bit encoders?

[El Heggunte]

Did I already mention that you should forget about 32-bit encoders?

Sín embargo, the 64-bit "supremacy" shouldn't be an excuse for careless programming

[Selur]

I wouldn't call it careless programming, but more a general problem of 32bit.
On a 32bit OS an application can use a maximum of 2GB of RAM.
A 8k image has a resolution of 7680x4320 so it has 33 177 600 pixels.
Depending on your color space you need quite a bit of RAM to hold one image inside memory.
32bit RGB = 32bit = 4 byte per pixel
24bit RGB = 24bit = 3 byte per pixel
Yv12 = 12bit = 1.5Byte per Pixel
Let's assume we only use Yv12 (4:2:0), that leaves us with 1.5*33 177 600 bytes (~ 47.46MB) per image.
Looking at frame rate of 25fps an a maximum gop size of 25 frames that is still 25*47.46MB = 1186.5MB.
Problem is that:
a. most people use larger gop sizes
b. you normally need to hold at least all the images inside of the current GOP inside the memory (to search for references&co)

-> Don't try to blame 'careless programming' if you haven't thought about what you are asking.

So yes, I would agree with LigH that 32bit encoders simply are not ment to handle such data masses.

[El Heggunte]

FWIW --- on my 32-bit machine, a Pentium-4 with 1GB of memory,

kvazaar.exe has managed to encode 6 frames of that 5616x3744 picture
(via Avisynth's ImageSource).

OTOH, x265 cannot even start to output one frame

[jb_alvarado]

I try here a high res compression, but first it doesn't work right and second the file size have not so much different to x264. Normally my clip has a resolution from 9600x1080 but I scale it down to 8192x922, I was thinking it help with the color error what I get. It looks like that it shifts the channels. The interesting thing is that x264 compress in 9600x1080 without problems.

Here are my setting:

ffmpeg64 -i input_%%04d.png -s 8192x922 -sws_flags lanczos -pix_fmt yuv420p -r 25 -t 00:00:10 -f yuv4mpegpipe - | x265 --input - --input-res 8192x922 --frames 250 --fps 25 --crf 22 -p slower -I 25 --output out.265

ffmpeg64 -i input_%%04d.png -s 8192x922 -sws_flags lanczos -pix_fmt yuv420p -r 25 -t 00:00:10 -an -c:v libx264 -crf 22 -preset slower -g 25 -y out.h264

mp4box -add out.265 output-x265.mp4

mp4box -add out.h264 output-x264.mp4

The x264 file have a size of 12,861 mb and the x265 file have a size of 11,076.

[Selur]

@El Heggunte:
So? kvazaar doesn't have any fancy motion estimation, adaptive GOP structures and similar.
Like the calculations I did show depending on your resolution and on how many frames are kept inside memory encoding 8k with 32bit is possible.
@jb_alvarado: have you tried using raw instead of y4m output?

[El Heggunte]

^ I see.

Therefore, what x265 needs is to become smart at "environment detection" and *circumstance management*

I mean, x265 should learn to not even start to try to do what it cannot do

[Selur]

I agree, that would be an option, but since x265 is more ALPHA then BETA or RELEASE CANDIDATE, this is something that isn't that important.
There are probably bigger and by far more important things to do atm. than make sure people to not feed the encoder with stuff that can't be handled.

[jb_alvarado]

@jb_alvarado: have you tried using raw instead of y4m output?

Thank you Selur, that was the trick! Now the file size looks also better: 8,661 mb and I think the quality is better then x264. Can it be by the same crf?

[El Heggunte]

Off-Topic break

Excerpt from the x265 freenode log

2014-03-15 19:33:20 < Easyfab> For information the 13-Mar-2014 version is ok so something breaks since the last 2 days . in x265 ?
2014-03-15 19:35:04 < JEEB> completely unsurprising
2014-03-15 19:35:13 < JEEB> x265 is not developed exactly like x264
2014-03-15 19:35:21 < JEEB> so expect random breakage at all points of development
2014-03-15 19:41:10 < Mandarinka> <JEEB> x265 is pretty fast now, preset placebo and refs/bframes maxed is now ~0.4fps with 720p on a i5 3570K
2014-03-15 19:41:37 < Mandarinka> can I ask what sort of source was used for that (and which bitrate)? Something that would result in a lot of skips?
2014-03-15 19:42:37 < Mandarinka> Because I tried 0.8 build by d404 on a quad phenom (so say half as fast as that Ivy Bridge), and I didn't even reach 0,01 fps (1440x1080 video with grain/motion, bitrate ended up high - 18000kbps)
2014-03-15 19:43:00 < JEEB> crf 32 or so methinks
2014-03-15 19:43:05 < Mandarinka> ah
2014-03-15 19:43:07 < JEEB> and 8bit of course
2014-03-15 19:43:08 < Mandarinka> probably helps
2014-03-15 19:43:12 < Mandarinka> yeah me too
2014-03-15 19:43:16 < JEEB> it was the hyouka op
2014-03-15 19:43:18 < Mandarinka> although I had wpp disabled (utilisation was still high) and bframes not maxed
2014-03-15 19:43:35 < Mandarinka> I guess the difference in bitrate could do a lot
2014-03-15 19:43:44 < JEEB> also 1440x1080 is not really 720p :P
2014-03-15 19:43:56 < Mandarinka> yeah, but still, two orders of magnitude
2014-03-15 19:44:00 < JEEB> also you might as well keep WPP enabled
2014-03-15 19:44:17 < JEEB> probably encodes quicker too, and the loss is so small in general
2014-03-15 19:44:24 < Mandarinka> I was wondering if the absence of ssse3 could critically cripple the performance...
2014-03-15 19:45:10 < Mandarinka> hmm, I guess I should try another encode, but those 450 frames took so long, I sorta don'T feel like repeating it haha
2014-03-15 19:45:44 < Mandarinka> and yeah, 0.4fps would be usable for encoding rips/fansubs.
2014-03-15 19:47:00 < JEEB> yup
2014-03-15 19:54:07 < Daemon404> Mandarinka, i am encoding at 0.02 fps with retardedl slow settings
2014-03-15 19:54:10 < Daemon404> 4k video
2014-03-15 19:54:18 < Daemon404> (on a 24 core xeon)
2014-03-15 19:55:48 < Mandarinka> is the particular hyouka op clip available somewhere for testing?
2014-03-15 19:56:23 < JEEB> I can link you it and the avs script I'm using for sourcing it
2014-03-15 19:56:26 < JEEB> sec
2014-03-15 19:57:21 < JEEB> linked in pm
2014-03-15 19:57:29 < JEEB> then for the avs...
2014-03-15 19:57:31 < Mandarinka> thanks
2014-03-15 19:58:46 < JEEB> LWLibavVideoSource(), Trim(96,2253), Spline36Resize(1280,720)
2014-03-15 19:58:52 < JEEB> that was it for the 8bit encode
2014-03-15 19:59:01 < Mandarinka> ok
2014-03-15 19:59:27 < Mandarinka> I tend to test oldies to see how grain gets wiped out/preserved
2014-03-15 19:59:30 < Daemon404> Easyfab, then x265 broke something
2014-03-15 19:59:46 < Mandarinka> in this case, New Cutie Honey BD.
2014-03-15 19:59:49 * Daemon404 mostly tests real content
2014-03-15 19:59:53 < Daemon404> from users
2014-03-15 20:00:15 < Mandarinka> Anybody interested in a 450 frames long 1440x1080 clip with 18 megabits bitrate, for testing or something?
2014-03-15 20:00:24 < Daemon404> nah
2014-03-15 20:00:28 * Daemon404 has all teh standard clips
2014-03-15 20:00:47 < Mandarinka> this one is nonstandard with nude transformation sequence.
2014-03-15 20:01:00 < Mandarinka> I guess since it took several days to make, I can upload it somewhere.
2014-03-15 20:01:04 < JEEB> anyways, with 8bit the CRF values I've been interested of so far are 32, 28, 24
2014-03-15 20:01:05 < Daemon404> well... vimeo does allow nudity
2014-03-15 20:01:08 < Daemon404> <.<
2014-03-15 20:01:08 < Daemon404> >.>
2014-03-15 20:01:21 < JEEB> 32 being definitely one that is low enough for artifacts to get shown
2014-03-15 20:01:26 < JEEB> 28 being somewhat better
2014-03-15 20:01:35 < JEEB> and 24 being close to what I usually use for encodes, I guess?
2014-03-15 20:01:38 < Mandarinka> I wasn't sure what to use, and the first number I tried ended up being superhuge
2014-03-15 20:01:55 < Mandarinka> I think I picked 18 (based on x264...)
2014-03-15 20:01:56 < Daemon404> im trying a 4k clip with 24
2014-03-15 20:02:01 < Daemon404> well see how it turns out in N hrs
2014-03-15 20:02:13 < JEEB> 18 is way too low to be of use
2014-03-15 20:02:35 < Mandarinka> well, I wanted to see how it does on high bitrates, actually
2014-03-15 20:03:01 < Mandarinka> but like 10-13 would be better (still an usable bitrate for a release...)
2014-03-15 20:03:02 < Daemon404> JEEB, im trying the same clip i tried in x264 vs $proprietary_hevc_encoder
2014-03-15 20:03:17 < JEEB> 24 to 22 is something that I consider relatively high bit rate
2014-03-15 20:03:23 < JEEB> very little visible artifacts if an
2014-03-15 20:03:25 < JEEB> *any
2014-03-15 20:03:33 < Daemon404> maybe for anime
2014-03-15 20:03:38 < Daemon404> because x265 biases towards blur
2014-03-15 20:04:00 < Mandarinka> actually, at that huge bitrate, x265 looked quite transparent in most places
2014-03-15 20:04:00 < JEEB> well, yeah -- I'm talking about blocking artifacts etc
2014-03-15 20:04:06 < Mandarinka> or, almost absolutely
2014-03-15 20:04:27 < Mandarinka> but in certain flat areas, it was washing the texture - curiously, only in some.
2014-03-15 20:04:34 < Mandarinka> well, 18 megabits, so...
2014-03-15 20:05:09 < Daemon404> [25.3%] 152/600 frames, 0.01 fps, 4232.53 kb/s, eta 10:33:39
2014-03-15 20:05:11 < Daemon404> crf 24
2014-03-15 20:05:21 < Daemon404> not that at ~5800, the proprietary encoder shat itself
2014-03-15 20:05:34 < Daemon404> anf x264 hadnoticable facts, but faired MUCH better
2014-03-15 20:05:41 < JEEB>
2014-03-15 20:13:28 < Easyfab> I see some psy-rd patch on x265-devel list so perhaps less blur soon
2014-03-15 20:14:26 < Mandarinka> that just a building block I think
2014-03-15 20:14:37 < JEEB> yeah
2014-03-15 20:14:53 < Mandarinka> it might be quite a struggle to make psyrdo behave in x265, give the differences
2014-03-15 20:15:28 < Mandarinka> also, x265 has RDO stuff taken over from HM (iirc?), so that might be a problem perhaps
2014-03-15 20:16:41 < Easyfab> Ok so no psyrdo soon
2014-03-15 20:17:51 < Mandarinka> well, it hasn't even been a year since the start of the project, let alone the public launch
2014-03-15 20:21:28 < smarter> Daemon404: are the proprietary hevc encoders any good?
2014-03-15 20:55:48 < Daemon404> lol
2014-03-15 20:55:53 < Daemon404> lol.
2014-03-15 20:56:55 * Mandarinka imagines a dude doing the same job at youtube, evaluating possible encoders for it.
2014-03-15 20:57:02 < Mandarinka> and then they get told to use VP9.
2014-03-15 20:57:46 < Mandarinka> although I guess VP9 could be made useful for youtube levels of "quality", because large portion of their videos are so horrible
2014-03-15 20:58:11 < nevcairiel> VP9 doesn't have bad quality really
2014-03-15 20:58:16 < nevcairiel> its just so extremely terribly slow
2014-03-15 20:58:24 < nevcairiel> (encoding)
2014-03-15 20:58:43 < Mandarinka> yeah, which is why I reckon they are using fast presets
2014-03-15 20:58:48 < nevcairiel> x265 moves like a lightning bolt in comparison
2014-03-15 20:59:15 < Mandarinka> I wonder how long those clips I tried last year took
2014-03-15 20:59:21 < Mandarinka> one was 2400 frames
2014-03-15 20:59:30 < Mandarinka> heh, but at least it was SD.
2014-03-15 20:59:50 < JEEB> youtube just cuts at GOPs and encodes like that so VP9's slowness is a bit less of a problem. But yes, they most definitely are not maxing the encoder out
2014-03-15 21:00:02 < nevcairiel> I got something like 3 fpm on a full HD encode at max quality settings
2014-03-15 21:00:08 < nevcairiel> a couple weeks back
2014-03-15 21:00:50 < JEEB> Mandarinka, grabbed the hyouka sample?
2014-03-15 21:00:51 < nevcairiel> using one core only of course
2014-03-15 21:00:59 < Daemon404> because there' a choice?
2014-03-15 21:01:00 < Daemon404> :P
2014-03-15 21:01:13 < nevcairiel> could employ splitting techniques
2014-03-15 21:01:19 < Daemon404> lol
2014-03-15 21:02:06 < nevcairiel> its not an invalid strategy really, just a bit complicated to pull off if you don't have a finished setup to run it
2014-03-15 21:02:22 < Mandarinka> JEEB: yeah, it has finished now.
2014-03-15 21:02:24 < JEEB> k
2014-03-15 21:02:47 < JEEB> I have coppelion's opening as well, which has some lulzy amounts of grain
2014-03-15 21:09:00 < Mandarinka> well, I think I will have enough just doing this. I'm really curious what will the performance be like
2014-03-15 21:09:28 < Mandarinka> probably best to start looking for a significantly faster cpu in any case
2014-03-15 21:45:53 < smarter> I think youtube use --cpu-used=1
2014-03-15 22:04:18 < nevcairiel> that parameter still has the weirdest name
2014-03-15 22:05:41 < Daemon404> what does it even do
2014-03-15 22:06:10 < nevcairiel> its the huge quality knob afaik
2014-03-15 22:06:17 < Daemon404> wtf?
2014-03-15 22:06:32 < Daemon404> i guess i get what it "means", but thats pretty. dmb
2014-03-15 22:06:36 < Daemon404> dumb*
2014-03-15 22:09:28 < nevcairiel> the parameter is a bit opaque really, it depends on the mode you used
2014-03-15 22:09:30 < Mandarinka> yeah, I agree
2014-03-15 22:09:48 < nevcairiel> vpx has a realtime encode mode where --cpu-used controls the target cpu usage of the encoder
2014-03-15 22:09:57 < nevcairiel> wonder how crappy it looks in realtime though
2014-03-15 22:10:02 < nevcairiel> or inefficient it is
2014-03-15 22:10:30 < Daemon404> probably uch wore than x264
2014-03-15 22:15:54 < smarter> realtime vp9 has been worked on a lot recently, but I haven't done any test
2014-03-15 22:16:14 < smarter> beating x264 is going to be tough

Full log attached below.

[DarrellS]

I tried running media-autobuild_suite-master from git and got errors saying that libpng and x265git failed. What do I do now? I can't find a source folder for either libpnd or x265git. There is a source folder for x265hg.


gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
C:\mingw\media-autobuild_suite-master\compile_globaltools.sh: line 250: cd: libpng-*: No such file or directory
C:\mingw\media-autobuild_suite-master\compile_globaltools.sh: line 251: ./configure: No such file or directory
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
-------------------------------------------------
build libpng-* failed...
delete the source folder under '/build32' and start again
first close the batch window, then the shell window




[ 1%] Building CXX object common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComDataCU.cpp.obj
In file included from c:/mingw/media-autobuild_suite-master/build32/x265-hg/source/Lib/TLibCommon/TComPic.h:46:0,
from c:/mingw/media-autobuild_suite-master/build32/x265-hg/source/Lib/TLibCommon/TComDataCU.cpp:40:
C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h: In constructor 'x265::ThreadSafeInteger::ThreadSafeInteger()':
C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h:220:42: error: 'InitializeConditionVariable' was not declared in this scope
InitializeConditionVariable(&m_cv);
^
C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h: In member function 'int x265::ThreadSafeInteger::waitForChange(int)':
C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h:232:60: error: 'SleepConditionVariableCS' was not declared in this scope
SleepConditionVariableCS(&m_cv, &m_cs, INFINITE);
^
C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h: In member function 'void x265::ThreadSafeInteger:et(int)':
C:/mingw/media-autobuild_suite-master/build32/x265-hg/source/common/threading.h:249:39: error: 'WakeAllConditionVariable' was not declared in this scope
WakeAllConditionVariable(&m_cv);
^
make[2]: *** [common/CMakeFiles/common.dir/__/Lib/TLibCommon/TComDataCU.cpp.obj] Error 1
make[1]: *** [common/CMakeFiles/common.dir/all] Error 2
make: *** [all] Error 2
-------------------------------------------------
build x265-git failed...
delete the source folder under '/build32' and start again