[HEVC] x265.EXE: mingw builds

[Selur]

And why do you assume what you downloaded there is an installer?
The binary I get from there is a normal x264 build with a renamed binary, so that the name shows the build version and type.
To make sure we speak of the same thing I zipped the file and attached it.

Cu Selur

[vhelp]

boy, this endevor (post # 1134) is turning into a pain.

[Selur]

Thats life
I spend the last 10hrs trying to compile a current version of mencoder&mplayer on mac os x 10.6.8 with libbluray, libass and the only thing I got form it is that I nearly fragged my system and had to reinstall an old image.

[vhelp]

nope, same thing. i don't install files like this. never. if i don't know what it is or can't see the files to extract, it gets deleted!

[poisondeathray]

nope, same thing. i don't install files like this. never. if i don't know what it is or can't see the files to extract, it gets deleted!

<snip>

Huh? It's just a compiled binary. There is nothing to install. Same with other x264.exe builds. Same with x265.exe and you've been using that...Open up x265.exe with 7zip and you will see similar things... Komisar's builds are safe and trusted

[Selur]

Yup, that's the way a normal binary looks like,...
My version I compile myself using https://github.com/jb-alvarado/media-autobuild_suite looks the same.

i don't install files like this. never.

-> Do you have any binary that doesn't look like that this and wasn't send through a binary packer or some sort of obscuration?

Cu Selur

[vhelp]

the x265.exe is an identifiable file that i can see and drag to my folder.

but guys, nevermind, this is becoming a battle. i just wanted to test something out in post # 1134 but i've lost interest now.

[poisondeathray]

the x265.exe is an identifiable file that i can see and drag to my folder.

This screenshot shows a binary in a zip file

Extract x265.exe from that archive, then open x265.exe with 7zip => what do you see ?

[Selur]

simply rename x264.2377.10bit.x86.exe to x264.exe and you got the same thing as the x265 binary for x264,..
(and if you 'open' the x265 binary it will look the the x264 binary)

[El Heggunte]

I asked Lentoid HEVC Decoder developers

Does not support 10bit decoding

I do not support the estimated short-term

Sadly you are right, this is what they told me:

Dear sir,
the Lentoid filter will not support 10-bit HEVC decoding in the near future, thanks for your kind reminder.
Best regards
service@strongene.com

[x265.cc]

They pushed the current version to 0.6

x265_0.6+3-55c0bf9d9966.zip


..and solved some issues.

[Selur]

for completeness here what Steve Borho send over the mailing list:

x265 0.6 is a regularly scheduled release

There were large improvements in compression efficiency since 0.5, mostly a
result of the completion of weightp and b-pyramid. There is also a large
amount of new assembly code; replacing most of the compiler intrinsic
functions and adding coverage for some new primitives.


= New Features =

* CLI reads input video from stdin
* Main10 profile is enabled, requires a HIGH_BIT_DEPTH build
* weightp is now complete enough to be enabled by default
* performance presets have been defined, matching x264 preset names
* b-pyramid (hierarchical B frames) now supported
* Constant Rate Factor rate control is considered stable
* Adaptive Quantization introduced, still experimental

Adaptive Quantization is still considered experimental. We are not always
seeing the expected improvements to SSIM when it is enabled, and thus it is
still not enabled by default.


= API Changes =

* x265_nal data members renamed
* x265_picture now has colorSpace member
* --weightp enabled by default
* default parameters now match our medium preset
* new x265_param_default_preset() method for assigning preset and tune
* new x265_param_alloc() and x265_param_free() methods for version safety
* new x265_picture_alloc() and x265_picture_free() methods for version
safety

The public data structures have changed enough that apps compiled against
previous versions of x265 must be recompiled to use x265 0.6. We are
taking steps to add version safety to the public interface. If you use the
new alloc/free methods for the param and picture structures, and use
x265_param_parse() to set param values by name, you will likely not have to
recompile your application to dynamically link against later releases of
x265.


= New CLI Options =

* --y4m overrides detection of Y4M input stream, ex: x265 --y4m - out.hevc
< vid.y4m
* --version long option alias for -V
* -p/--preset sets performance preset
* -t/--tune sets parameter tuning
* --[no-]b-pyramid enabled by default
* --input-csp color space parameter, only i420 is supported in this release
* --crf constant rate factor rate control
* --aq-mode and --aq-strength

See x265 --help for more details


= Upcoming improvements =

* motion compensated weightp analysis (using lookahead data)
* CU-tree (MBtree adapted from x264)
* VBV rate control
* assembly for HIGH_BIT_DEPTH builds

[chie]

ICC X265 0.6+3-55c0bf9d99661073
8bpp 64bit
speed better than build with MSVC

[x265.cc]

ICC X265 0.6+3-55c0bf9d99661073
8bpp 64bit
speed better than build with MSVC

My benchmark:

x265_GCC.exe input.y4m -o output.hevc:

encoded 300 frames in 11.36s (26.42 fps), 27.60 kb/s, Global PSNR: 39.074


x265_ICC.exe input.y4m -o output.hevc:

encoded 300 frames in 11.89s (25.24 fps), 27.60 kb/s, Global PSNR: 39.074


x265_VC12.exe input.y4m -o output.hevc:

encoded 300 frames in 11.98s (25.04 fps), 27.60 kb/s, Global PSNR: 39.074

On an Intel based machine, AMD based machine should be more worse with the icc binary.

If i prefer speed, i would prefer the gcc build.

[vhelp]

win xp home sp2
amd dual core x2 3600+ 2gig ram
x265 mingw 8bpp builds -- (MMX2 SSE SSE2Slow SlowCTZ)
source is a dvd rip -- 720x480 24p 100 frames

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---

guys, post your rig specs when you quote stats like this. i got so excited and tried, but found to my sad surprise that i was not affected by any improvements, getting the same speed as from previous builds.

i was unable to obtain the new stdin support and have to continue using the older stdin/pipe method for 0.6+3 build. old stdin/pipe method: cmd /S /C avs2yuv "c:\video.avs" -raw -o - |

--preset ultrafast --crf 17 --input - -o h:\video.hm10

results:
100 frames in 40.73s (2.45 fps), 0993.04 kb/s, PSNR: 46.915 -- vsize 528KB, x265 0.5+676
100 frames in 42.09s (2.32 fps), 1072.84 kb/s, PSNR: 47.016 -- vsize 570KB, x265 0.6+003

[Selur]

@vhelp: there is no 'new' stdIn method, the changelog simply states that since the start of 0.5 stdIn support has been added.

[LigH.de]

@ vhelp:

I don't understand why 7-zip attempts to open an executable and show completely normal code and data segments of every Windows EXE to people who don't need to know how a linker works. Apparently it only causes confusion and scares the paranoid. Read some documentation about the "Win32 Portable Executable" specifications. If it looks like in #1144, it is a plain EXE, not a self-extracting archive.
__

@ x265.cc:

I start to wonder if builds before v0.5 might better be moved to a kind of "archive", to improve clarity in your buildbot download directories. Just a little food for thoughts, no demand.

[x265.cc]

I start to wonder if builds before v0.5 might better be moved to a kind of "archive", to improve clarity in your buildbot download directories. Just a little food for thoughts, no demand.

Done.

guys, post your rig specs when you quote stats like this. i got so excited and tried, but found to my sad surprise that i was not affected by any improvements, getting the same speed as from previous builds.

I only wanted to say something like "there's no black magic in the ICC build".

[LigH.de]

The more code (especially in tight loops) already depends mostly on handcrafted assembler optimizations, the less a C compiler can still improve the speed.

Furthermore, other compilers are already quite aggressive as well. The distance to the former "legendary" intel C compiler keeps shrinking.
__

Is there any more verbose documentation about the new RD value range (v0.5: 0..2; v0.6: 0..6 {def.: 3})?

[vhelp]

** note, same system specs as in post # 1155 **

i noticed a small increase in encoding speed. same source dvd rip -- 720x480 24p 100 frames and 1805 frames test encodes

1805 frames encodes in:

12m42s using 0.6+31 build
09m10s using 0.6+72 build

--preset ultrafast --crf 17 --input - -o h:\video.hm10

results:
100 frames in 40.73s (2.45 fps), 0993.04 kb/s, PSNR: 46.915 -- vsize 528KB, x265 0.5+676
100 frames in 42.09s (2.32 fps), 1072.84 kb/s, PSNR: 47.016 -- vsize 570KB, x265 0.6+003
100 frames in 31.27s (3.20 fps), 1082.87 kb/s, PSNR: 47.018 -- vsize 576KB, x265 0.6+072

[Selur]

Nice to see, that PSNR and speed are increasing for the ultrafast preset.

[LigH.de]

But a better technical metric value (PSNR, SSIM) does not necessarily mean a better subjective impression (less annoying artefacts)...

[Selur]

No, not necessarily.

[deadrats]

But a better technical metric value (PSNR, SSIM) does not necessarily mean a better subjective impression (less annoying artefacts)...

PSNR and SSIM are both very valid when testing non-psy related changes within a codec and they are also very valid when comparing the encoded output of an encoder against an uncompressed reference source.

it's only once you start talking about various types of psychovisual optimizations that the math metric supposedly stop having a meaningful correlation to subjective quality, but i won't go any fuirther since everyone already knows my stance on that topic.

[Stears555]

But a better technical metric value (PSNR, SSIM) does not necessarily mean a better subjective impression (less annoying artefacts)...

PSNR and SSIM are both very valid when testing non-psy related changes within a codec and they are also very valid when comparing the encoded output of an encoder against an uncompressed reference source.

it's only once you start talking about various types of psychovisual optimizations that the math metric supposedly stop having a meaningful correlation to subjective quality, but i won't go any fuirther since everyone already knows my stance on that topic.

I can confirm, that x265 is 25% to 50% better (based on situation and video material) than x264.

[deadrats]

I can confirm, that x265 is 25% to 50% better (based on situation and video material) than x264.

you won't hear any argument from me on that topic, i would just point out that x265 doesn't have any psy optimizations yet and it already beats x264 even with all its highly vaunted psy optimizations.

it's a function of the superior compression scheme, the divxh265 encoder also beats x264, so...

[vhelp]

- how to - mini guide, someone asked how do you stdin/pipe through ffmpeg -> x265.exe, so i am repeating it here.

fps - 23.976, 24, 25, 30, 29.970 -- fps need to be specified in both utilities: ffmpeg and x265.exe
resolution - 720x480, 1920x1080, etc. -- resolutions need to be specified in both utilities: ffmpeg and x265.exe
(ffmpeg) pixel format - yuv420p -- 8bit, specified only in ffmpeg, x265.exe takes care of it through its { --input - } command.
(ffmpeg) pixel format - yuv420p10le -- 10bit, then add to x265_16bpp.exe { --input-depth 10, --input-csp i420 } commands.

this assume 24fps, and will encode *all* frames. make sure to adjust to match your videos:

cmd /s /c ffmpeg -i c:\template-video1.avs -s 720x480 -r 24 -f rawvideo  -pix_fmt yuv420p - | x265.exe --preset ultrafast --crf 17 --input-res  720x480 --fps 23.976 --output "h:\video.hm10" --input -

if you want to encode a small section of video, then you need to modify the video.avs script
to include a trim() statement. be sure you have avisynth installed on your computer or it won't work.

if last line in video.avs has trim(0,100) it will encode from frame 0 to 100 or 100 frames.

if last line in video.avs has trim(100,500) it will encode 400 frames starting at frame 100.
(make sure your video resolutions are the same, for the video.avs and output hevc encoded videos.hm10)

cmd /s /c ffmpeg -i c:\template-video1.avs -s 720x480 -r 24 -f rawvideo  -pix_fmt yuv420p - | x265.exe --preset ultrafast --crf 17 --input-res  720x480 --fps 23.976 --output "h:\video.hm10" --input -

** note, some computers/os's don't need the { cmd /s /c } so test first without.

[Fllear]

After compiling. New build x265 falls.


And the question is where the settings before compiling x265? And how to build a 64-bit version on GCC?
Because in their cmake not even almost.

[El Heggunte]

@Fllear:

in the CMake GUI, before "configuring" and "generating", tick the checkbox "treat warnings as errors".

Later, copy the compiler error message, and send it to the x265 mailing list.

[Fllear]

@Fllear:

in the CMake GUI, before "configuring" and "generating", tick the checkbox "treat warnings as errors".

Later, copy the compiler error message, and send it to the x265 mailing list.

I asked the question how to fix or where to send it!
I asked how to configure compilation. Ie how to compile a 64-bit version and more. When compiling via MinGW, cmake settings in almost all present.