[HEVC] x265.EXE: mingw builds

[vhelp]

i don't know of any way to create 10/16bit videos for testing in 16bpp x265 versions unless i missed the obvious.

my understanding is, source video should be either 10bit or 16bit, and the sw player should be capable of playing back in that bit-depth. i'm not sure how to correctly do this. the only way i could test this is to feed a tipical 8bit video, encode it and play it back. that is what i did in the test (below) and playback was successful in at least one.

i suspect that you did not feed a true 10bit video source. you gave it an 8bit video source, and when you issue the --input-depth 10, the encoder is interpreting and encoding to the 10 sampling. the playback is giving you garbage as a result because it is missinterpreting your original 8bit video as if a 10bit, so the sw player is decoding it as 8bit or vise-versa. find out how to create a 10bit video source and then retry that.

also, just noticed, you may need to fill in these as well:

--input-res x,y --fps 23.976 (if film)

successfull
--preset ultrafast --input-res 720x480 --fps 23.976 --frame-skip 0  --frames 100 --crf 17 --b-adapt 2 --merange 1 --me 4 --ref 1 --input - -o "video.8bit.hm10"

unsuccessfull
--bitrate 2000 --input-depth 10 --subme 7 --rdpenalty 1  --no-strong-intra-smoothing --b-adapt 2 --weightp --aq-mode 1 --rd 2 --sao-lcu-bounds 1 --sao-lcu-opt 0 --input - -o "video.10bit.hm10"

successfull when in normal view, but fullscreen causes problems.  probably the other parameters causing them.
--bitrate 2000 --input-depth 8 --subme 7 --rdpenalty 1  --no-strong-intra-smoothing --b-adapt 2 --weightp --aq-mode 1 --rd 2 --sao-lcu-bounds 1 --sao-lcu-opt 0 --input - -o "video.8bit.hm10"

[dimokami]

OK thanks, I'll trying.

[vhelp]

but i think you'll still have probelms unless your video source is true 10bit.

so i did a little searching around and i found that the Drastic YCbCr VFW Codec (which i already have in my system) can output 10bit, (fourcc v210) after 8bit->10bit conversion, and verified in virtualdub that its 10bits. but we can't feed that directly into x265.exe, we have to convert it to avisynth and then feed to x265.exe --input-bitdepth 10 to encode. but no success, yet.

i am trying to find a way to feed 10bit videos into avisynth -> avs2yuv -> x265.exe but that is not happening because avisynth (and/or avs2yuv, or both) always outputs 8bit videos.

using avisynth -> avisource(video.[codec=v210].10bit.avi) -> virtualdub reports 8bits yv12
using avisynth -> l-smash(video.[codec=v210].10bit.avi) -> doesn't work
using avisynth -> ffms2(video.[codec=v210].10bit.avi) -> virtualdub reports yuy2

therefore, i believe x265.exe is not yet ready to accept 10bit videos, yet, until it features full video input sources of any kind. i could be wrong.

[vhelp]

ok, finally got it, but give me a few minutes to type if out in next post.

[El Heggunte]

ok, finally got it, but give me a few minutes to type if out in next post.

Time's up

[Marchand]

vhelp

Sample input-H264 Hi10p with outlet Hevc.H265 Main10 profile, Level-4 (Main tier) running normally.

[vhelp]

@ Marchand, you're running 64bit windows 7 and codecs, i don't know that os system and can't verify its validity.

@ el heggunte, sorry, taking a little longer, since i am re-verifying the steps as i write it. almost complete...more time..

[Marchand]

vhelp

Win 7 -64bits - Service Pack 1 - Intel Quad Core 2,67 Ghz
CCCP Codec Pack - 23.11.09 - Beta - Avisynth 2.5

[dimokami]

Strange I made by x264 10bit encoder file and put it into VirtualDub and encode from it to x265, but my file still broke. Decoder in VD x264fvw by http://komisar.gin.by/

[vhelp]

before i complete this guide (i may have to ditch it depending on answers) let me ask a couple of questions..

@ Marchand
which x265.exe build exactly did you use ?
can you point exactly which version on this page: https://x265.cc/
i will download it (again if i have to) but it has to be xp 32bit version.

[Marchand]

Vhelp

HEVC encoder version 0.5+600-ec904fab863a - 32bit

x265-8bpp-vc12 - 32bit
x265-16bpp-mingw - 32bit
x265-16bpp-vc12 - 32bit

x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x-x

Cool.

Has left the new version ... go for the tests.

encoder (x265.exe):
rev 0.5+617-833d78aaf71e (UTC 12:19:03 PM)

Completed conversion ( Sample input-H264 Hi10p with outlet Hevc.H265 Main10 profile, Level-4 (Main tier) running normally )

------------------------------------------------------------------------------------------------------------------------------
[C:\Users\Marchand\Videos\teste HI10PxHevc10bits.mp4]
------------------------------------------------------------------------------------------------------------------------------
auo [info]: converting YC48 -> i420p(10bit)
auo [info]: x265 options...
--input-depth 10 --input-csp i420 --preset ultrafast --bitrate 1200 --rc-lookahead 20 --keyint 240 --bframes 3 --b-adapt 1
--ctu 64 --me 1 --merange 60 --ref 2 --frames 7694 --input-res 1920x1080 --fps 24 -o "C:\Users\Marchand\Videos\teste
HI10PxHevc10bits.265" "-"
yuv [info]: 1920x1080 24Hz C420, frames 0 - 7693 of 0
x265 [info]: using cpu capabilities: MMX2 SSE SSE2Fast SSSE3 SSE4.1 Cache64
x265 [info]: HEVC encoder version 0.5+600-ec904fab863a
x265 [info]: build info [Windows][GCC 4.8.2][32 bit] 16bpp
x265 [info]: Main10 profile, Level-4 (Main tier)
x265 [info]: WPP streams / pool / frames : 17 / 4 / 2
x265 [info]: Input bit depth : 10
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 60 / 0 / 2
x265 [info]: Keyframe min / max : 240 / 240
x265 [info]: Rate Control : ABR-1200 kbps
x265 [info]: Lookahead / bframes / badapt : 20 / 3 / 1
x265 [info]: b-pyramid / weightp / ref : 1 / 0 / 2
x265 [info]: tools: cfm esd rd=0
x265 [info]: I-frame 64..4: 21% 28% 16% 19% 14%
x265 [info]: P64: Split 46% Merge 37% Inter 10% Intra 6%(DC 37% P 9% Ang 53%)
x265 [info]: P32: Split 31% Merge 46% Inter 12% Intra 9%(DC 23% P 8% Ang 67%)
x265 [info]: P16: Split 21% Merge 50% Inter 13% Intra 13%(DC 20% P 6% Ang 73%)
x265 [info]: P8 : Split 0% Merge 42% Inter 25% Intra 31%(DC 19% P 7% Ang 73% 4x4 0%)
x265 [info]: B64: Split 15% Merge 76% Inter 8%
x265 [info]: B32: Split 20% Merge 62% Inter 17%
x265 [info]: B16: Split 15% Merge 57% Inter 26%
x265 [info]: B8 : Split 0% Merge 43% Inter 56%
x265 [info]: frame I: 146 kb/s: 7286.42 PSNR Mean: Y:46.222 U:45.107 V:45.046
x265 [info]: frame P: 4230 kb/s: 1427.07 PSNR Mean: Y:41.172 U:41.951 V:41.840
x265 [info]: frame B: 3318 kb/s: 652.03 PSNR Mean: Y:40.399 U:38.937 V:38.652
x265 [info]: global : 7694 kb/s: 1204.02 PSNR Mean: Y:40.934 U:40.711 V:40.526
auo [info]: x265ѓGѓ“ѓRЃ[ѓhЋћЉФ : 1ЋћЉФ17•Є47.6•b
auo [info]: NeroAacEnc ‚Е‰№ђєѓGѓ“ѓRЃ[ѓh‚рЌs‚ў‚Ь‚·ЃB AAC-LC ѓrѓbѓgѓЊЃ[ѓgЋw’и, 128kbps
auo [info]: L-SMASH muxer ‚Еmux‚рЌs‚ў‚Ь‚·ЃB‰f‘њ: on, ‰№ђєff, tcff, Љg’Јѓ‚Ѓ[ѓh:‚И‚µ
auo [info]: L-SMASH remuxer ‚Еmux‚рЌs‚ў‚Ь‚·ЃB‰f‘њ: on, ‰№ђє: on, tcff, Љg’Јѓ‚Ѓ[ѓh:‚И‚µ
auo [info]: ‘ЌѓGѓ“ѓRЃ[ѓhЋћЉФ : 1ЋћЉФ18•Є18.0•b

[vhelp]

hmm... me things that the 32bit builds for 16bpp is borked, probably in all of the versions. i tried the latest 0.5+617 16bpp and Marchand's 0.5+600 16bpp (32bit) build versions and the filesize of were 7kb, when it should be 4mb. i will have to d/l all the 16bpp versions to test. sheesh!

[vhelp]

the guide i was working on is for creating the 10bit source.

can you provde me that 10bit source video you used ?
i assume you didn't create it. or, did you use an 8bit video source and x265 converted it to 10bit ?

ps: when i encode to 10bit, i do not see this in my finished output log:

auo [info]: converting YC48 -> i420p(10bit)
auo [info]: x265 options...

[Marchand]

vhelp

Have'm uploading the sample pure H264 (Hi10p) for you to do the tests (138MB)

Just a little step you have the link to download

https://shared.com/fwxmmix993?s=l

[vhelp]

unfortunately, the file download keeps crapping out. it won't complete, probably because it keeps popping up adds and things and eating up my download so it timesout. i will try and search around for a 10bit video. thank you for trying. i think the method i was using to create them are sound, but the sampling that the codec uses may not be correct for x265.exe and i don't know the correct sampling it expects.

[vhelp]

@ Marchand, can you upload a short x265 encoded 10bit clip ?

let me test the playback of that instead. if the clip plays fine, then its sampling problem on my end, but if it does playback properly like the others, then its a decoder issue on my system. thank you.

[vhelp]

still unable to encode playable 10bit videos with { 0.5+617 32bit 16bpp mingw } or any build using your "100.mkv" source.

i was looking at your last param string, seems to be from a log file of some sort. so it doesn't look normal to me. seems some missing parts to it. must be a front-end gui you are using. i need to see how you are feeding the 100.mkv source file into x265. if it is through stdin/piping, then i need to see that. this should work, running inside a dos console window, but doesn't playback properly:

cmd /s /c avs2yuv "c:\video.avs" -raw -o - | x265_0.5+600-ec904fab863a.16bpp.exe --preset ultrafast --input-res 1920x1080 --fps 23.976 --input-depth 10 --input-csp i420 --frames 10 --crf 17 --input - -o "h:\video.10bit.hm10"

cmd /s /c avs2yuv "c:\video.avs" -raw -o - | x265_0.5+617-833d78aaf71e.16bpp.exe --preset ultrafast --input-res 1920x1080 --fps 23.976 --input-depth 10 --input-csp i420 --frames 10 --crf 17 --input - -o "h:\video.10bit.hm10"

if you are using avisynth, how are you calling the "100.mkv" file in the script ?

i don't see this, and is from your post, which is mysterious to me:

auo [info]: converting YC48 -> i420p(10bit)

[vhelp]

i have to give up on this one. it is a relentless deadend. if i make one change from

--input-depth 10 to --input-depth 8

the video plays back fine. this must be a windows xp 32bit mingw 16bpp build problem with x265.exe and is broken in all the builds and never checked. well, its 2am.

[El Heggunte]

vhelp: "converting YC48 -> i420p(10bit)" smells like an LSmashSource AVS file...

Regarding the 10-bit encodes: with the latest 16bpp build, all I get is a 12-frame (0.5 seconds) unplayable file, OR an epic crash

Since we are not allmighty creatures nor ecoterrorists , let's pray that the x265 devels themselves start doing more tests and less "patches" And/or stop using their project as a questionable excuse for practicing their CMake skills

[Selur]

@El Heggunte:

that the x265 devels themselves start doing more tests and less "patches"

git development is a patch driven development, so a lot of patches is kind of a philosophical thing
Also if I remember correctly the developers mentioned that high bit depth encoding is not stable enough for usage, so it's not really a surprise that some versions produce broken output for high bit depth.
Or has there been some additional infos from the developers I missed?

@x265:

For example, the number of rate distortion (--rd) levels is being expanded ...

source: latest evaluation guide
okay, the rate distortion optimization now got 7 instead of 3 values, any insight what the differences are between the 7 levels?
0 : least
1 : ?
2 : ?
3 : ?
4 : ?
5 : ?
6 : ?
7: full
side note:

/*Level of Rate Distortion Optimization Allowed */
typedef enum {     
 X265_NO_RDO_NO_RDOQ, /* Partial RDO during mode decision (only at each depth/mode), no RDO in quantization */ 
 X265_NO_RDO,         /* Partial RDO during mode decision (only at each depth/mode), quantization RDO enabled */     
 X265_FULL_RDO        /* Full RD-based mode decision */
} X265_RDO_LEVEL;

source:
https://bitbucket.org/multicoreware/x265/src/2786f9e925609e73f0f504bdb0ea2a1e13ea0d35/...5.h?at=default
only shows 3 levels,...

Also adding more presets might be a good idea, since 'placebo' isn't really a placebo setting atm.

[vhelp]

ok, i believe i finally got it, by golly. i'm waiting for this snail computer to finish the test encode.

edit: 1

for now, see if this short test video plays in your sw player. go to the info and see what the codec says. i need a longer clip to for vlc to verify it longer.

[vhelp]

i believe we were doing it all wrong initially. we don't give it any source and x265.exe encode it. i thought that x265.exe "converts" to 10bit. but it doesn't seem to, or i could be wrong. it is probably sampling to 10 bit during encoding. we need to serve the source video a true 10 bit source. if we do it this way, correctly, then x265.exe will properly write the sampling to the video as it encodes it. then, when played back, the video is yuv decoded properly.

[vhelp]

so, our problem is, how do we get a true 10bit video source ? well, i spent all day researching this and doing countless and relentless trial and error encodes. and, with the added stdin/piping feature, via avs2yuv and avisynth, this is not possible since these two only serve 8bit video. there are hacks (so i've read a few passages, thanks google) but that is not appropriate for most users.

so, the only way to serve a true 10bit video source is to create one via raw yuv. yep...back to creating raw yuv.

hopefully, someone has confirmed that clip i posted is an hevc 10bit playable video.

[Selur]

You assumed x265 would create a 10bit output if you feed it with a 8bit input and specified '--input-depth 10'?-> you might want to request a "--output-depth X" option

Shouldn't avs2yuv create 'real' 10bit yuv? (assuming your avisynth script create it, using in example dither (http://forum.doom9.org/showthread.php?p=1386559)?)

so, our problem is, how do we get a true 10bit video source ?

ProRes content used during editing normally is 10bit,...

[dimokami]

So no chances to encode 10bit? Or some faq you have?

[Selur]

@vhelp: quick goole search -> 10bit samples: http://www.sounddevices.com/products/pix220i/sample-files/

[x265]

@x265:

For example, the number of rate distortion (--rd) levels is being expanded ...

source: latest evaluation guide
okay, the rate distortion optimization now got 7 instead of 3 values, any insight what the differences are between the 7 levels?
0 : least
1 : ?
2 : ?
3 : ?
4 : ?
5 : ?
6 : ?
7: full
side note:

/*Level of Rate Distortion Optimization Allowed */
typedef enum {     
 X265_NO_RDO_NO_RDOQ, /* Partial RDO during mode decision (only at each depth/mode), no RDO in quantization */ 
 X265_NO_RDO,         /* Partial RDO during mode decision (only at each depth/mode), quantization RDO enabled */     
 X265_FULL_RDO        /* Full RD-based mode decision */
} X265_RDO_LEVEL;

source:
https://bitbucket.org/multicoreware/x265/src/2786f9e925609e73f0f504bdb0ea2a1e13ea0d35/...5.h?at=default
only shows 3 levels,...

Also adding more presets might be a good idea, since 'placebo' isn't really a placebo setting atm.

Selur,
I don't want to publish code or internal discussions from one of our developers. The responsible developer will publish the patch when it is ready. In general, --rd 0 will perform a minimal amount of rate distortion optimization, and --rd 6 will perform all possible optimizations. I added this warning to the Evaluator's Guide as a general caution when you are running new builds taken from the development tip. The Guide is aimed at users running the latest stable build.

Patches are simply how all new or changed code is published for review by the open source community. We have a 24 hour review cycle for most contributions. This was requested by the open source developer community, and we agreed that it is a good practice. Developers write new code, export the changes as a patch (a standard file format showing what files are affected by the change, and what lines of code were added or subtracted to those files). Doing work in smaller increments also allows problems to be isolated to the change that may have caused the problem.

BTW, there is a bug in the current development tip causing Placebo mode to crash. Stay away from Placebo mode until you see a patch fixing this bug.

Tom

[vhelp]

Shouldn't avs2yuv create 'real' 10bit yuv? (assuming your avisynth script create it, using in example dither (http://forum.doom9.org/showthread.php?p=1386559)?)

@ selur, i read that topic that you linked to, but it was too confusing for me to understand. it was not straight forward. you need the mvtools or whatever its called and other things. and you have to be familiar with these plugins and their usage. i ain't got that kind of time or patience for that. thats another reason i never use the qtmc for deinterlacing...all that stuff you need to have.

[Selur]

I added this warning to the Evaluator's Guide as a general caution when you are running new builds taken from the development tip. The Guide is aimed at users running the latest stable build.

Thanks for the explanation.
I see, you added a warning which had nothing to do with the current state of the code. Odd, but okay, that explains my confusion.

[Selur]

@vhelp: For testing, you could, decode a 10bit sample with ffmpeg (iirc it should support ProRes and DnxHD; select a raw 10bit output format ) and pipe the output to x265.

typical 10bit output formats would be:
- yuv420p10le
- yuv422p10le
- yuv444p10le
(ffmpeg lists all the pixel formats it supports if you call 'ffmpeg -pix_fmts')