[HEVC] x265.EXE: mingw builds

[LigH.de]

Commit fabb25a is here.

This build crashes too while quitting when option "--weightp" is used.

Additionally, option"-w" (shortcut for "--weightp") is not supported.



Is there a bug tracker where such comments are more appreciated than here?
__

P.S.:

Remark for x265.cc — you list MPC-HC as "decoder" on your site; but MPC-HC does not yet support HEVC, not even in nightly builds. MPC-BE's nightlies do, instead.
__

P.P.S.:

The MP4 splitter is probably the weak link in MPC-HC. Unconfirmed by me, yet.

[El Heggunte]

......................

Is there a bug tracker where such comments are more appreciated than here?

https://mailman.videolan.org/listinfo/x265-devel

and/or

smtp://steve-ÄT-borho-D0T-org

[tnti]

http://code.google.com/p/lavfilters/source/list

Support HEVC decoding
Support HEVC demuxing

MPC-HC is also fast can decode HEVC
@El Heggunte

[x265.cc]

Remark for x265.cc — you list MPC-HC as "decoder" on your site; but MPC-HC does not yet support HEVC, not even in nightly builds. MPC-BE's nightlies do, instead.

It's meant in combination with Strongene Decoder. Due to the support of h265 by lavfilters (and the mpc-hc usage of lavfilters) mpc-hc will support h265 soon anyway (out of the box)

btw. as you probably noticed, the buildbot is not this automated as it should. This is due to improvement/enhancement (WinXP and 16bpp builds) and should be fixed/ready tomorrow (in combination with a new build server).

[El Heggunte]

Hmmmmmm......

[El Heggunte]

Commit f1bdaca available at http://x265.cc

[LigH.de]

Versions, revisions, long hashes, short hashes ... someone explain this naming to me.
__

Anyway:

r479 finished the 360crop test without crashes. So I took the chance to run it with the FullHD version too.

x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc -F 3 -q 20 -b 3 --b-adapt 2 --bframe-bias 30 -w --ref 3 -i 240 --psnr --ssim --rdpenalty 1 --csv sintel_trailer_1080.csv

Great quality at "-q 20". Because I didn't trust the log about "Global SSIM: 0.995", I made a RawSource+Subtract().Levels() script to emphasize the differences. Result: It is probably true. Differences are minimal.

And despite Shazeb Khan's opinion that

weighted prediction (--weightp) is yet not ready to work with frameparallelism (-F 3)

(from the developer mailinglist), I spotted no data corruption artefacts.

Pasted console log

[El Heggunte]

@ LigH: thanks for your useful posts on the mailing list

@ all: get commit 6d96d64 from http://x265.cc/

[Fllear]

Very well played by MPC BE. Even madvr works.
Coded slice. And shows a container with any sound.

[tnti]

http://www.mediafire.com/download/7ok41p49twmza5m/%5BTSDM-Xrip%5D%5BFate_Kaleid_Liner_...%5BHEVC%5D.mp4


[TSDM-Xrip][Fate_Kaleid_Liner_Prisma_Illya][01][BIG5][720P][HEVC].mp4




I would use BD encoding a HEVC video

[Fllear]

Encode 4K

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L15.0
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 1mn 30s
Bit rate : 11.4 Mbps
Maximum bit rate : 32.5 Mbps
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.057
Stream size : 123 MiB (98%)
Title : OWA Raws Test Encode h265 4K
Encoded date : UTC 2013-10-23 17:58:41
Tagged date : UTC 2013-10-23 17:58:41


Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 1mn 32s
Bit rate mode : Variable
Bit rate : 256 Kbps
Maximum bit rate : 263 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 2.81 MiB (2%)
Title : AAC Audio Japan
Encoded date : UTC 2013-10-23 17:58:41
Tagged date : UTC 2013-10-23 17:58:41

[tnti]

Well done



However, the encoding time is too long

[Fllear]

Well done



However, the encoding time is too long

Ohh

[tnti]

X265 Evaluators Guide can follow the appropriate reduction parameter




After modifying parameters will be much faster encoding speed



https://bitbucket.org/multicoreware/x265/wiki/Performance

[Fllear]

X265 Evaluators Guide can follow the appropriate reduction parameter




After modifying parameters will be much faster encoding speed



https://bitbucket.org/multicoreware/x265/wiki/Performance

If you follow what is written there. The video quality will drop dramatically just.

[tnti]

Appropriate quality can be reduced in exchange for faster encoding speed
At this stage, then it is the pursuit of picture quality is good with X264

[Fllear]

Appropriate quality can be reduced in exchange for faster encoding speed

Well, if you take your video. You have all the pixels breaks. And there are no such qualities. Your encode albeit with a Blu-Ray, , but the quality is not drawn to 720p.

[tnti]

That is not the BD 720P video as source video encoding

Later I will release BD as the source video encoding HEVC video

[Fllear]

That is not the BD 720P video as source video encoding

Later I will release BD as the source video encoding HEVC video

Hmmm)) Well, I will soon be released.
[OWA Raws] Blood Lad - Vol.01 (BD 1280x720 h265 Vorbis Chap)

[tnti]

Well done

Waiting for your work

[Selur]

Is there some overview of the min and max values of each x265 option somewhere?
(the command line help only shows some values)

[x265.cc]

My buildbot rewrite is done, still some upload issues, everything else should be fine.

Buildbot host:

Windows Server 2012 R2 Datacenter (x64)
Visual Studio 2012 Ultimate / Update 3
MinGW with GCC 4.8.2
Yasm 1.2.0

Currently builds x265 every 30 Minutes with 8 bpp and 16 bpp for WinXP and later.

WinXP compatible systems are named "VC11-legacy".

btw. stdin yuv patch will be integrated soon, if the x265 project will not do it anway.

[El Heggunte]

Buildbot host:

Windows Server 2012 R2 Datacenter (x64)
Visual Studio 2012 Ultimate / Update 3
MinGW with GCC 4.8.2
Yasm 1.2.0

Not a word about that infamous http server named nginx?

Come on man, nginx is evil Evil EVIL ,

downgrade to Apache 1.3.27 already

[Selur]

Got question about "8 bpp and 16 bpp".
Since HEVC only supports 8bit, 10bit and 12bit pixel precision, does it have something to do with the (output) color space sampling?
-> What does it indicate?

[Fllear]

My buildbot rewrite is done, still some upload issues, everything else should be fine.

Buildbot host:

Windows Server 2012 R2 Datacenter (x64)
Visual Studio 2012 Ultimate / Update 3
MinGW with GCC 4.8.2
Yasm 1.2.0

Currently builds x265 every 30 Minutes with 8 bpp and 16 bpp for WinXP and later.

WinXP compatible systems are named "VC11-legacy".

btw. stdin yuv patch will be integrated soon, if the x265 project will not do it anway.

Any crashes your encoder with me. In all settings, even.

[x265.cc]

Any crashes your encoder with me. In all settings, even.

Can you tell me which x265.exe you are using? And what you mean with "crashes" (at the beginning, end, etc.)?

I only build them, i do not check the source for bugs.

Anyway, i've now tested version 0.4.1+528-4ca4da7bdd36, VC11, 64bit, 8bpp on Windows 7 Enterpise SP1 x64, and it works.



//edit: same version build with MinGW:



//edit2: VC11 x64 Version works on Windows 8.1 Enterprise x64 too.

[Fllear]

I am all that there is builds used. Falls right at the start, time to encode 10-15 frames after Windows severs process.

[x265.cc]

I am all that there is builds used. Falls right at the start, time to encode 10-15 frames after Windows severs process.

Can you try to convert this file for testing purposes: http://media.xiph.org/video/derf/y4m/akiyo_qcif.y4m
using https://x265.cc/builds/VC11-x86_64/8bpp/x265_0.4.1%2b528-4ca4da7bdd36.zip

Tested on an CLEAN (only Windows Updates) Win 8.1 Ent x64 english system:



btw. if the mingw builds also fail, its probably a source and/or x265 related problem.

[tnti]

This is the BUG X265

Please help report BUG
@El Heggunte

[x265.cc]

http://www.mediafire.com/download/nkm8xm558m7xcxq/x265_16bpp_528-4ca4da7_64bit_.7z


x265_16bpp _528-4ca4da7_64bit .7z

C:\x265>x265 -V
x265 [info]: HEVC encoder version 0.4.1+528-4ca4da7bdd36
x265 [info]: build info [Windows][MSVC 1700][32 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.1 Cache64
x265 [info]: performance primitives: intrinsic assembly