[HEVC] x265.EXE: mingw builds

[El Heggunte]

@hiritsuki: well, for now I can only suggest you try a GCC build, instead of a VC build.

IF other error messages or crashes happen, THEN "something else" ( a stupid firewall, a stupid antivirus, a stupid printer driver, go figure ) on your machine is interfering with the most recent versions of x265.exe...

BTW, and this comment is targeted at the x265 devs, I keep seeing no good reason for the existence of the MSVC builds of x265.

[LigH.de]

What is "sorathread()" ... a third-party plugin for multithreaded plugin execution? Is this at all necessary, since AviSynth 2.60 MT with SetMTMode()?

And, by the way: Why accellerating Yadif, which is already fast, compared to many other deinterlacers, and especially compared to x265? Multithreading should accellerate the slowest part of the sequence, not the average fast. That shall happen inside x265, not inside AviSynth.

[Selur]

@LigH:

a third-party plugin for multithreaded plugin execution?

Yes -> Sora's avs multi-process/multi-thread plugin package

[hiritsuki]

@El Heggunte
Ah!... sorry..I'll try GCC build. thanks.

[hiritsuki]

Ah... I find a new problem of the --tcu is can't set 32 or lower

It's normal??

[Selur]

-s/--ctu Maximum CU size (width and height)
Values: 16, 32, 64 (Default)

from the evaluation guide, so only these three values are valid

[hiritsuki]

@Selur

thanks a lot.

I'll try again

[Selur]

btw. you can download the evaluation guide over at: https://bitbucket.org/multicoreware/x265/downloads

[vhelp]

- x265_0.5+439-108ddc9e5c6b.exe (MSYS-x86/8bpp builds) - this build is borked. i tested the stdin/pipe and standard raw yuv, just in case it was that, but it does not seem to be, it just crashes when it starts to encode.

[LigH.de]

VC12-x86_64 passed for Y4M file input and raw yuv pipe. MSYS-x86 crashes.

[hiritsuki]

VC12-x86_64 passed for Y4M file input and raw yuv pipe. MSYS-x86 crashes.

And it's random.. right?

[LigH.de]

No, reliably crashing so far. But that may depend on the CLI options used.

I let run a batch with all avaliable 'presets' and some additional options. They all crashed after reporting the encoding options: "x265 [info]: tools: ...".

VC12-x86 crashes as well. Only VC12-x86_64 runs on my Windows 7 SP1 64-bit. Reported a suspicion about a target architecture dependent issue to the developer mailinglist.

[hiritsuki]

I means the crash timing is random.

[hiritsuki]

Maybe the weighted is crash's problem ,I'll try again.

[Fllear]

WTF Profile 10bith depth ??

[Selur]

and? no info about encoder version, command line options,... -> what is the surprise for?

[Fllear]

and? no info about encoder version, command line options,... -> what is the surprise for?

http://ftp.kw.bbc.co.uk/hevc/hm-10.0-anchors/bitstreams/

[Selur]

Okay, so you posted a non x265 created clip in the "x265.EXE: mingw builds" thread, to show your surprise about what?
That there are HEVC streams with 10bit output precision?
Shouldn't be a surprise, HEVC has a Main10 profile and with the Range Extension it even has a Main12 profile.
-> unless there is a question related to x265 somewhere, you better open a new thread and formulate a question there.

[Fllear]

Okay, so you posted a non x265 created clip in the "x265.EXE: mingw builds" thread, to show your surprise about what?
That there are HEVC streams with 10bit output precision?
Shouldn't be a surprise, HEVC has a Main10 profile and with the Range Extension it even has a Main12 profile.
-> unless there is a question related to x265 somewhere, you better open a new thread and formulate a question there.

Then why not have a version with these profiles?
I think to an 8-bit general can have long forgotten.
Even if you finish it when the x265, 8-bit profile itself is not needed.
For in this case, but it does not say 10-bit x264 profile is better than him.
Let's say I'm doing exclusively with the profile High 10 in x264. As soon as it came out, it became immediately clear that this is an 8-bit past.

[Selur]

Then why not have a version with these profiles?

Simply because, like mentioned before, the high bit-deth code hasn't been rewritten/optimized.
Going from 8bit to 10/12/16bit precision isn't that simple and can be easily done.
If you want to speed-up the Main10 support, contact the x265, tell them what you can do and they might have an idea how you can help.

[Fllear]

Then why not have a version with these profiles?

Simply because, like mentioned before, the high bit-deth code hasn't been rewritten/optimized.
Going from 8bit to 10/12/16bit precision isn't that simple and can be easily done.
If you want to speed-up the Main10 support, contact the x265, tell them what you can do and they might have an idea how you can help.

Sent the letter. I'll wait for an answer on this.

[vhelp]

i'm all for quality, but such higher bit features are for sources that *originate* from 10/12/16 bit and that will stay in that bit range. that is the benefit. and, its still too early to be attempting to take advantage of any of this, for any source bit range. you may have read 8bit source processing inside 10bit during noising editing/filter cleansing/etc where there are certain advantages but its not exactly the same thing for playback. its like adding extra bits where there is none, and at 59.94 fileds/sec you aren't going to see anything spectacular with current sw players. you are waisting gas for nothing. otherwise, as others shown, please produce a/b sources, x265.exe build ver, full param string usage, video specs (fps, dimen, length) encoding time, etc.

[Selur]

@vhelp: using higher bit precision also helps with:
a. compression
b. banding, which is caused due to rounding errors
so encoding 8bit input to 8+bit output can make sense

[Fllear]

i'm all for quality, but such higher bit features are for sources that *originate* from 10/12/16 bit and that will stay in that bit range. that is the benefit. and, its still too early to be attempting to take advantage of any of this, for any source bit range. you may have read 8bit source processing inside 10bit during noising editing/filter cleansing/etc where there are certain advantages but its not exactly the same thing for playback. its like adding extra bits where there is none, and at 59.94 fileds/sec you aren't going to see anything spectacular with current sw players. you are waisting gas for nothing. otherwise, as others shown, please produce a/b sources, x265.exe build ver, full param string usage, video specs (fps, dimen, length) encoding time, etc.

10-bit video fits very well to the anime.
Even if the source is only 8-bit, the output encoding it in 10-bit, we will get more compressibility of the video source, as well as the lack of banding. Encoding in 8-bit would have a lot of bit rate to use as opposed to 10-bit. So be sure to say that 10-bit is a great profile, and it does not matter what the source 8-bit.

To save the gradient does not require dash noise (dither) This reduces the size.

[El Heggunte]

INFO: commit db1151b returns a compiler error at 15% ---
--- already reported @ the mailing list

[ 15%] Building CXX object encoder/CMakeFiles/encoder.dir/slicetype.cpp.obj
F:/GITS/X265/1121/source/encoder/slicetype.cpp: In member function 'void x265::Lookahead::slicetypeDecide()':
F:/GITS/X265/1121/source/encoder/slicetype.cpp:827:18: error: 'list[-1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         TComPic *list[X265_BFRAME_MAX + 1];
                  ^
cc1plus.exe: all warnings being treated as errors
make[2]: *** [encoder/CMakeFiles/encoder.dir/slicetype.cpp.obj] Error 1
make[1]: *** [encoder/CMakeFiles/encoder.dir/all] Error 2
make: *** [all] Error 2

NOTE: "all warnings being treated as errors" = *ALWAYS ON*, because
the x265 project is not the x264 project

[x265.cc]

Due to an technical malfunction of one of our ups, there were no new builds for ~24 hours. Im sorry for that.

JYFI, due to the much new asm code, the build time have been increased by arround ~100% from early version 0.4 to latest version 0.5

[El Heggunte]

@x265.cc: how about sorting the directory listings in strictly chronological order

I hope that it's doable in nginx...

[x265]

Then why not have a version with these profiles?

Simply because, like mentioned before, the high bit-deth code hasn't been rewritten/optimized.
Going from 8bit to 10/12/16bit precision isn't that simple and can be easily done.
If you want to speed-up the Main10 support, contact the x265, tell them what you can do and they might have an idea how you can help.

Main 10 support can be considered beta quality from what I understand (I haven't tested it myself yet). Early / interested adopters are free to build the 16 bit/sample version of x265 and start to do some tests. Feedback is welcomed (you can post anecdotal feedback here, but we welcome detailed bug reports with your system config and steps to reproduce the bug including a link to your video source file and your x265 command line on the x265-devel mailing list).

Tom

[x265.cc]

@x265.cc: how about sorting the directory listings in strictly chronological order

Erm, yeah i think thats a great / useful idea.

I hope that it's doable in nginx...

afaik not with official nginx. I must do this by patching the source code or using an external script / program. Probably i will do this at weekend.

[LigH.de]

- x265_0.5+439-108ddc9e5c6b.exe (MSYS-x86/8bpp builds) - this build is borked. i tested the stdin/pipe and standard raw yuv, just in case it was that, but it does not seem to be, it just crashes when it starts to encode.

x265 0.5+524-5009254d3d3a:

• MSYS-x86 8bpp passed.
• VC12-x86 8bpp passed.
• VC12-x86_64 8bpp passed.

__

P.S.:

JYFI, due to the much new asm code, the build time have been increased by arround ~100% from early version 0.4 to latest version 0.5

The encoding time is the important benchmark.