[HEVC] x265.EXE: mingw builds

[vhelp]

to encode 10bit, your source has to be 10bit already.

a few posts up, there was a post made with a 10bit sample, "100.zip" where the actual filename is 100.mkv, but the problem with that file was there was no method to feed it through the usual way into the x265.exe app. he was using a custom gui that did behind-the-scemes steps to feed to the x265.exe app, and i wasn't able to determine what they were and so i could not use the source to test it.

even if you have a 10bit source, you need to know to feed it to the x265.exe app. there are crude hack methods posted in other forums, (see selur's link above) that shows a way to serve 10bit. but, good luck with that. they are not straightforward to understand. you have to do some reading to figure these things out unless someone spoon feeds it to you.

[vhelp]

@ selur, yes, i know. as i was saying initially in post # 1101, i figured it all out already, by myself. no one helped, damnit! as i told el_heggunte before, and i 'll say it again...they always come and help, but only after you've spend the day or weeks figuring it out!

[vhelp]

- how to convert an 8bit video to 10bit video - mini guide
- how to encode it with x265.exe
- how to test the encode for 10bit success

1. edit/clean/crop/cut/format your input video source (ie, avisynth) if using avisynth, give it a simple same, ie, video.avs
2. next, we want to create a raw 10bit yuv video from step 1
3. so, open a dos console window and enter the following, but change frame rate and dimension to match yours
4. ffmpeg -i "c:\video.avs" -s 720x480 -r 29970/1000 -f rawvideo -pix_fmt yuv420p10le -y "g:\video.yuv420p10le.10bit.yuv"
5. then, using x265.exe and your favorite --preset, enter the following, substitute frame rate and dimension to match yours
6. --preset ultrafast --input-depth 10 --input-csp i420 --input-res 720x480 --fps 29.970 --crf 17 --input "g:\video.yuv420p10le.10bit.yuv" -o "h:\video.10bit.hm10"
7. encode
8. find an updated hevc capable sw player, ie, vlc v2.1.1 download and install that
9. to test playback with vlc, open the hevc video from step 6 and play it.
10. while the video is playing in vlc, press Ctrl+J and observe the codec info. it should say 10-Bit LE
11. finished

[El Heggunte]

@vhelp --- many big THANKS! for the detailed info

Additional notes:

--- your 10-bit HEVC sample is decoded OK by LAV video, but not by the Lentoid filter
(so it's time to pester the Strongene people again, I guess)

--- it's possible to use "pipe" between ffmpeg and x265, so there is no need for an intermediate YUV file
Example:

ffmpeg -i video10.avs -s 320x576 -r 24 -f rawvideo -pix_fmt yuv420p10le -|5618x265
--input-res 320x576 --fps 24 --input-csp i420 --input-depth 10 --BLAH-BLAH-BLAH -o zehnbitsample.265 -

General
Complete name                            : zehnbitsample.265
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
File size                                : 58.6 KiB

Video
Format                                   : HEVC
Format/Info                              : High Efficiency Video Coding
Format profile                           : Main 10@L6.3
Width                                    : 320 pixels
Height                                   : 576 pixels
Display aspect ratio                     : 0.556
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 10 bits

[Selur]

but only after you've spend the day or weeks figuring it out!

From time to time, sleep is needed and the real world also is demanding attention.

it's possible to use "pipe" between ffmpeg and x265, so there is no need for an intermediate YUV file

That's why I wrote " decode ... with ffmpeg ... and pipe the output to x265".

[Selur]

btw. the whole thing should also work (haven't tested) with mencoder:

mencoder -lavdopts threads=8 -really-quiet -of rawvideo -o - -ovc raw -demuxer lavf -vfm ffmpeg -noskip -vf scale,format=i420,scale,format=420p10le -forcedsubsonly -nosub -nosound -mc 0 "PATH TO INPUT" | x265-16bit --input - --input-depth 10 ..

"-vf scale,format=i420,scale,format=420p10le"
scale,format=i420 <- tells mencoder that the input is 4:2:0
scale,format=420p10le <- tells mencoder that the output is 420p10le (4:2:0 10bit little endian)
-> doesn't work for some reason, seens like rawvideo doesn't like 420p10le

Cu Selur

[vhelp]

selur, imo, mencoder is evil. the commands are horrible to get working. unless i'm mistaken, i don't see any advantage it might have over others like ffmpeg, in my projects.

--- it's possible to use "pipe" between ffmpeg and x265, so there is no need for an intermediate YUV file

thank you for the tip. i managed to get it to work in my project. i have to use the (crippling) windows cmd.exe for the stdin/pipe to work though.

cmd /s /c ffmpeg -i c:\video.avs -s 720x480 -r 24 -f rawvideo -pix_fmt yuv420p10le - |

ps: it seems we have to raise the bitrate for 10bit videos. they don't look very good with the bitrate i've been using for the 8bit videos. also, i installed the latest mediainfo.dll and use that for determining the bit-depth of these videos. thanks for that tip as well.

[Selur]

@vhelp:

the commands are harible to get working.

Don't think the commands are anywhere easier or more complicated then they are for ffmpeg.

i don't see any advantage it might have over others like ffmpeg, in my projects.

can't tell you if mplayer/mencoder has any advantage for you, I mainly use mencoder because:
a. it has the same syntax as mplayer (sadly ffplay has no slave mode like mplayer)
b. it can handle dvd input
c. has some other filters (sadly it is also lacking some)
d. mplayer can support a of additional formats through vfw (codecs folder)

-> for me both ffmpeg&mencoder have their merit

Cu Selur

[tnti]

Strongene Lentoid HEVC Decoder does not support 10bit hevc

Maybe you should use the script to the video jitter 10bit encode again


Use dither.avsi Or enter a 10bit video


Add -- recon-depth 10 --input-depth 10

[Selur]

why "-- recon-depth 10" ? doesn't make any sense to me,....

[tnti]

X265 is no built-in 8bit 10bit conversion code

You should read x265 Evaluators Guide Nov 29 2013


Instead of asking me

--recon-depth


Bit-depth of output file


Default: same as input bit depth

[Selur]

So you have no clue why you recommend a setting,... *gig*

[El Heggunte]

FWIW --- I've already sent yet another e-mail to the Strongeners =^.^=

And for the curious: yes, x265 can generate 12-bit streams as well --- confirmed by MediaInfo

The problem is, so far only TAppDecoder is able to decompress the damn thing

[tnti]

--aq-mode 1 Need -- RD 2 ？ @X265


I asked Lentoid HEVC Decoder developers


Does not support 10bit decoding


I do not support the estimated short-term

LAV Filters can support the main 10 hevc

[vhelp]

is tappdecoder stdin/pipe'able at least ?

[vhelp]

another thing, i don't get why encoded 8bit videos are larger than 10bit ones. ie,

 8bit, 100 frames, 1,226kb
10bit, 100 frames,   260kb

could this be a bug or something wrong in the encoding parameters ?

the 8bit is much higher quality while the 10bit is nearly horrible.

[vhelp]

so tested some more and found that --crf seems borked for 10bit videos, and you have to use --q instead. then the filesize became equivalent.

i always use --crf 17 as my standard setting for my particular videos, thus, --q 17 was used in the 10bit encode.

 8bit, 100 frames, 1,226kb 
10bit, 100 frames, 1,443kb

[tnti]

Estimate is a BUG CRF-induced

10bit and 8bit video volume should not have such a big gap


Maybe ask the developer under the X265?

[poisondeathray]

Not sure what the case is for x265, but in x264 the crf and qp scale is different for 8bit vs 10bit

For 8bit it goes from 0-51 , For 10bit it goes from 0-63 . So they are not functionally equivalent


For x265, --help shows
--crf Quality-based VBR (0-51). Default 28.000000

but I assume that is for 8bit

[vhelp]

x265.exe 0.5+618, mingw, 16bpp build. this is the build i have currently. 
i'm sure it has updated already and would give same results.

 8bit, 100 frames, 1,226kb --crf 17
10bit, 100 frames,   260kb --crf 17
10bit, 100 frames, 1,443kb --q   17

they are both the same "range of values" for x265 (h265)

--bitrate  Enables ABR rate control. Specify the target bitrate in kbps.
           Range of values: An integer greater than 0

--crf      Quality-based VBR
           Range of values: an integer from 0 to 51, (def: 28)

-q/--qp    Base Quantization Parameter for Constant QP mode
           Using this option causes x265 to use Constant QP rate control (def)
           Range of values: an integer from 0 to 51, (def: 32)

[poisondeathray]

they are both the same "range of values" for x265 (h265)

Same for x264 for qp and crf ; the range is the same using the same binary.

The point was the scale is different for 8bit vs. 10bit when using x264. ie. crf17 in 8bit is not similar to crf17 in 10bit encoding . They are functionally different scales

The x265 help doesn't say if that applies to 8bit vs. 10bit . Your observations would suggest there is a difference in range of values, just like x264

[Selur]

is tappdecoder stdin/pipe'able at least ?

no

about the size:
a. crf will, like it does in x264, produce different sizes depending on what settings you selected along side it
b. 10/12/16bit should be smaller than 8bit encoding, but not that much -> I agree that this probably is a bug with in crf high-bitdepth methods
c. quantizer and rate factor are two totally different things, they just got the same scale to make it a bit easier for folks to have a general idea about crf

[vhelp]

The x265 help doesn't say if that applies to 8bit vs. 10bit . Your observations would suggest there is a difference in range of values, just like x264

no, i'm not talking about comparing 8 vs 10 bit quality encodes with crf or q methods. only pointing out that they are very far apart in quality/size when using the same value. but i get what you are saying, however..

then there must be something wrong with --crf and 10bit because to get close to the same level of quality from that { 8bit --crf 17 } encode when i had used {10bit --crf 1 } and at "1" that should have been nearly lossless (which it wasn't and still less quality than the 8bit encode) so there may be a problem with that aspect of the code if both are using the same range of value in the scale. i know that we are not comparing crf to q here, though the filesize should have been somwhere near, even +/- 200kb or so.

[vhelp]

out of curiosity, i want to test x264.exe to see what results i get with the same source. soon as i learn how via google since i don't know the command for input-depth and input-csp. be back later with the results.

[Selur]

for x264:

      --input-csp <string>    Specify input colorspace format for raw input
                              - valid csps for `raw' demuxer:
                                i420, yv12, nv12, i422, yv16, nv16, i444, yv24, bgr, bgra, rgb
                              - valid csps for `lavf' demuxer:
                                yuv420p, yuyv422, rgb24, bgr24, yuv422p, 
                                yuv444p, yuv410p, yuv411p, gray, monow, monob, 
                                pal8, yuvj420p, yuvj422p, yuvj444p, xvmcmc, 
                                xvmcidct, uyvy422, uyyvyy411, bgr8, bgr4, 
                                bgr4_byte, rgb8, rgb4, rgb4_byte, nv12, nv21, 
                                argb, rgba, abgr, bgra, gray16be, gray16le, 
                                yuv440p, yuvj440p, yuva420p, vdpau_h264, 
                                vdpau_mpeg1, vdpau_mpeg2, vdpau_wmv3, 
                                vdpau_vc1, rgb48be, rgb48le, rgb565be, 
                                rgb565le, rgb555be, rgb555le, bgr565be, 
                                bgr565le, bgr555be, bgr555le, vaapi_moco, 
                                vaapi_idct, vaapi_vld, yuv420p16le, 
                                yuv420p16be, yuv422p16le, yuv422p16be, 
                                yuv444p16le, yuv444p16be, vdpau_mpeg4, 
                                dxva2_vld, rgb444le, rgb444be, bgr444le, 
                                bgr444be, gray8a, bgr48be, bgr48le, yuv420p9be, 
                                yuv420p9le, yuv420p10be, yuv420p10le, 
                                yuv422p10be, yuv422p10le, yuv444p9be, 
                                yuv444p9le, yuv444p10be, yuv444p10le, 
                                yuv422p9be, yuv422p9le, vda_vld, gbrp, gbrp9be, 
                                gbrp9le, gbrp10be, gbrp10le, gbrp16be, 
                                gbrp16le, yuva420p9be, yuva420p9le, 
                                yuva422p9be, yuva422p9le, yuva444p9be, 
                                yuva444p9le, yuva420p10be, yuva420p10le, 
                                yuva422p10be, yuva422p10le, yuva444p10be, 
                                yuva444p10le, yuva420p16be, yuva420p16le, 
                                yuva422p16be, yuva422p16le, yuva444p16be, 
                                yuva444p16le, vdpau, xyz12le, xyz12be, nv16, 
                                nv20le, nv20be, rgba64be, rgba64le, bgra64be, 
                                bgra64le, 0rgb, rgb0, 0bgr, bgr0, yuva444p, 
                                yuva422p, yuv420p12be, yuv420p12le, 
                                yuv420p14be, yuv420p14le, yuv422p12be, 
                                yuv422p12le, yuv422p14be, yuv422p14le, 
                                yuv444p12be, yuv444p12le, yuv444p14be, 
                                yuv444p14le, gbrp12be, gbrp12le, gbrp14be, 
                                gbrp14le, gbrap, gbrap16be, gbrap16le, 
                                yuvj411p, bayer_bggr8, bayer_rggb8, 
                                bayer_gbrg8, bayer_grbg8, bayer_bggr16le, 
                                bayer_bggr16be, bayer_rggb16le, bayer_rggb16be, 
                                bayer_gbrg16le, bayer_gbrg16be, bayer_grbg16le, 
                                bayer_grbg16be
      --output-csp <string>   Specify output colorspace ["i420"]
                                  - i420, i422, i444, rgb
      --input-depth <integer> Specify input bit depth for raw input
      --input-range <string>  Specify input color range ["auto"]
                                  - auto, tv, pc
      --input-res <intxint>   Specify input resolution (width x height)

[vhelp]

thanks, so its the same, great. it seems the old site is gone, but i found this one: http://download.videolan.org/pub/x264/binaries/win32/

and d/l'ed the "x264-10b-r2377-1ca7bb9.exe" file but it is an installer type and i can't extract the exe file.

do you know of another resourse where i can d/l it ?

[Selur]

x264 binaries -> http://komisar.gin.by/

[vhelp]

unfortunately, its another installer, and broken into several ".rdata" pieces and i can't extract the file from it. i don't know they went with this method.

[Selur]

only the vfw version is an installer, all others are not and why would you want to download the vfw version, if you want a command line tool

[vhelp]

i d/l'ed the 3rd one down.

--- UPD: 2013-10-31 CLI-version 2377 ---
2377.x86
2377.x86_64
2377.10bit.x86 <-- d/l 'ed
2377.10bit.x86_64
--- vfw ---