[HEVC] x265.EXE: mingw builds

[El Heggunte]

INFO (again):

Performance of Strongene Lentoid Decoder = very good
Performance of the modified MPC FLV Splitter = very good

Performance of Strongene MP4 Demuxer = poor
(easily detectable on a slow machine)

Performance of the Osmo4 Player = poor
(easily detectable on a slow machine)

That's all, folks.

[DarrellS]

@DarrellS, where are those command functions in vdub ? i have v1.9.11

You have to have 1.10.0 or later and you have to create the encoder sets. I could upload my vdprof (file that stores your encoder sets) file so you don't have to manually create them. Encoders without stdin "-" cannot be used and no-one can get encoders that use scripts like WMEncoder and the Lentoid to work.

There are guides on the Virtualdub forum to show how to use the external encoder feature...

http://forums.virtualdub.org/index.php?act=ST&f=3&t=18840&
http://forums.virtualdub.org/index.php?act=ST&f=5&t=18789&

...and a few threads here. Budman has a website also that explains how to use it with his downloadable vdprof files.

Here is my updated vdprof file. Just rename to .vdprof and under Options > External Encoder > choose Import and choose the vdprof file and click OK. You have to download all the CLI encoders (if you have Selurs Hybrid program, it has most of them in the Hybrid folder) and change the path to the encoders. It is recommended to keep your encoders in C:\Tools to make them easier to find and easier to share the vdprof files.

My projects right now are trying to get x265 and vp9 working.

[DarrellS]

i thought i would add this notation here, just in case others are experiencing the same playback issue pheonima as i am currently.

if you download and install the Osmo software player, it will playblack the following (any -one- of these encoded-to-.mp4) succesfully:
(note 1, you don't have to rename the source file anymore, but if you do, just pick the encoding string below that matches)
(note 2, dont' forget to include the :FMT=HEVC or it won't work correcty)
(note 3, and don't forget to update your -fps according to your video's frame rate)

mp4box -add h:\video1.h265:FMT=HEVC -fps 23.976 -add h:\audio.aac -new h:\video.mp4

.or.

mp4box -add h:\video1.hm10:FMT=HEVC -fps 23.976 -add h:\audio.aac -new h:\video.mp4

but we still need to know how to resolve/fix the issue with playing back on *all* software players, those that might have the same problem as i am having over here:
https://forum.videohelp.com/threads/358035-muxing-audio-and-video-from-hevc-encode-to-f...72#post2259872

i do not know where you can download the Osmo player. perhaps someone does and can post the link!

http://gpac.wp.mines-telecom.fr/downloads/gpac-nightly-builds/
Here

Yeah, I thought you had to download the GPAC nightly build to be able to mux the mp4

[vhelp]

thanks for the help, very appreciated

[Trepack]

Up-to-date Whit commit 8338cad

x265 encoder version 0.3+245-8438cad92049-Build-Whit-MinGW


Happy testing

[El Heggunte]

Build-vc11-support XP Test:

x265 encoder version 0.3+245-8438cad92049-Build-Whit-vc11-x86[support XP]

Happy testing

Steve Borho is much lazier than I thought, he's lucky because his employers are not aware of the fact

The InterlockedCompareExchange64 thing is only part of the problem, it's not the entire problem.

Again,

"x265.exe is not a valid Win32 application."

[Trepack]

Will be a matter of waiting for them to fix the problem

[El Heggunte]

[ intentionally left blank ]

[Trepack]

Up-to-date whit commit 8d7ffa0

x265 encoder version 0.3+256-8d7ffa0d7433

[x265]

[QUOTE=El Heggunte;2260062]

Build-vc11-support XP Test:

Steve Borho is much lazier than I thought, he's lucky because his employers are not aware of the fact

That's not nice. As Steve replied on the x265-devel mailing list...

Interesting problem. We don't have an explicit list of supported Windows operating systems. Microsoft itself is abandoning support for XP next April (http://windows.microsoft.com/en-us/windows/end-support-help), so I hesitate to make this our default build setting. I can see two options: 1 - Document this on the wiki - tell people to build on Win XP if they want to run on XP, or set this in their build flag 2 - Add this as a cmake option, similar to the flag which enables statically linked CRT binaries. Leaning towards solution 2

Our primary focus right now is to provide the performance and quality that everyone needs in a practical HEVC encoder. This is a fairly large and challenging project. The current To Do list is posted here... https://bitbucket.org/multicoreware/x265/wiki/TODO but a simpler way of looking at this is to realize that most people want near HM quality HEVC in real-time or faster on affordable hardware. And they want this performance for 4K video, with no chroma subsampling, at 10 bits/pixel, with high frame rates. Our team is focused on delivering this kind of performance on typical professional platforms (to start, this kind of performance will require a modern multi-cpu server system with 16 cores or more). As we go forward, we'll expand support to more platforms... but Windows NT wouldn't be at the top of the list .

Tom V
MulticoreWare

[El Heggunte]

build 8d7ffa0 seems OK

@Trepack: we won't mind if you set up and run an autobuilder for x265.exe

Just kidding, of course --- thanks again for the collaboration.

[El Heggunte]

NEW version of the x265 Evaluators Guide is out:

https://bitbucket.org/multicoreware/x265/downloads

[deadrats]

[QUOTE=x265;2260211]

Build-vc11-support XP Test:

Steve Borho is much lazier than I thought, he's lucky because his employers are not aware of the fact

That's not nice. As Steve replied on the x265-devel mailing list...

Interesting problem. We don't have an explicit list of supported Windows operating systems. Microsoft itself is abandoning support for XP next April (http://windows.microsoft.com/en-us/windows/end-support-help), so I hesitate to make this our default build setting. I can see two options: 1 - Document this on the wiki - tell people to build on Win XP if they want to run on XP, or set this in their build flag 2 - Add this as a cmake option, similar to the flag which enables statically linked CRT binaries. Leaning towards solution 2

Our primary focus right now is to provide the performance and quality that everyone needs in a practical HEVC encoder. This is a fairly large and challenging project. The current To Do list is posted here... https://bitbucket.org/multicoreware/x265/wiki/TODO but a simpler way of looking at this is to realize that most people want near HM quality HEVC in real-time or faster on affordable hardware. And they want this performance for 4K video, with no chroma subsampling, at 10 bits/pixel, with high frame rates. Our team is focused on delivering this kind of performance on typical professional platforms (to start, this kind of performance will require a modern multi-cpu server system with 16 cores or more). As we go forward, we'll expand support to more platforms... but Windows NT wouldn't be at the top of the list .

Tom V
MulticoreWare

if i may make one suggestion...instead of focusing on achieving your performance goals on x86 hardware why not focus on a cuda version of x265, a version where you can take advantage of the massive parallelism afforded by modern gpu's. my understanding is that the h265 spec was designed from the ground up for relatively easy threading, so you could achieve real time 4k encoding with an sli top of the line cards and real time 1080p encoding on mid-range graphics cards.

of course i have already predicted the failure of the x265 project to become the hevc encoder of choice of the average video enthusiast so please don't prove me wrong.

[x265]

if i may make one suggestion...instead of focusing on achieving your performance goals on x86 hardware why not focus on a cuda version of x265, a version where you can take advantage of the massive parallelism afforded by modern gpu's. my understanding is that the h265 spec was designed from the ground up for relatively easy threading, so you could achieve real time 4k encoding with an sli top of the line cards and real time 1080p encoding on mid-range graphics cards.

of course i have already predicted the failure of the x265 project to become the hevc encoder of choice of the average video enthusiast so please don't prove me wrong.

Right now we are focused on optimizing the algorithms, and we're doing this on x86 hardware. We are parallelizing the encoder wherever possible. MulticoreWare has one of the largest and most capable engineering teams in the world specializing in parallel computing of all types (OpenCL, CUDA, Renderscript, C++ AMP, HSA). We are the team that brought OpenCL acceleration to x264. You can be sure that we understand how to take full advantage of all of the available hardware on a system.

Anyhow... good suggestion. We agree with the concept in general, but we have to take care of first things first, and when it comes to accelerating x265 using heterogeneous computing architectures, there are a number of possibilities, but you can count on MulticoreWare to live up to our name.

Tom
MulticoreWare

[Trepack]

Up-to-Date whit commit a2026f0

x265 encoder version 0.3+293-a2026f0e1556

[x265]

There are a number of changes being made right now. We're updating the Evaluator's Guide, but in the meantime, if you run x265 -h you will see some new options and default settings...

Syntax: x265 [options] infile [-o] outfile
infile can be YUV or Y4M
outfile is raw HEVC bitstream
Options:

Standalone Executable Options:
-h/--help Show this help text
Default: Enabled
--cpuid Limit SIMD arch 0:auto 1:None 2:SSE2 .. 8:AVX2
Default: 0
--threads Number of threads for thread pool (0: detect CPUcore count)
Default: 0
--log Logging level 0:ERROR 1:WARNING 2:INFO 3EBUG -1:NONE
Default: 2
--csv `Comma separated value' log file, appends one line per run
--no-progress Disable progress reports
-o/--output Bitstream output file name

Input Options:
--input Raw YUV or Y4M input file name
--input-depth Bit-depth of input file (YUV only)
Default: 8
--width Source picture width, auto-detect if Y4M
Default: 0
--height Source picture height, auto-detect if Y4M
Default: 0
--rate Frame rate, auto-detect if Y4M
Default: 0
--frame-skip Number of frames to skip at start of input file
Default: 0
-f/--frames Number of frames to be encoded (0 implies all)
Default: 0

Reconstructed video options (debugging):
-r/--recon Reconstructed image YUV or Y4M output file name
--recon-depth Bit-depth of output file
Default: 8

Quad-Tree analysis:
--no-wpp Disable Wavefront Parallel Processing
--wpp Enable Wavefront Parallel Processing
Default: Enabled
-s/--ctu Maximum CU size (default: 64x64)
Default: 64
--tu-intra-depth Max TU recursive depth for intra CUs
Default: 3
--tu-inter-depth Max TU recursive depth for inter CUs
Default: 3

Temporal / motion search options:
--me Motion search method 0:dia 1:hex 2:umh 3tar 4:full
Default: 3
--merange Motion search range
Default: 64
--bpredrange Motion search range for bipred refinement
Default: 4
--no-rect Disable rectangular motion partitions Nx2N and 2NxN
--rect Enable rectangular motion partitions Nx2N and 2NxN
Default: Enabled
--no-amp Disable asymmetric motion partitions
--amp Enable asymmetric motion partitions, requires --rect
Default: Enabled
--no-rdo Enable mode decision without rate distortion optimization
--rdo Enable rate distortion-based mode decision
Default: Enabled
--max-merge Maximum number of merge candidates
Default: 5
--no-early-skip Disable early SKIP detection
--early-skip Enable early SKIP detection
Default: Disabled
--no-fast-cbf Disable Cbf fast mode
--fast-cbf Enable Cbf fast mode
Default: Disabled

Spatial / intra options:
--rdpenalty penalty for 32x32 intra TU in non-I slices. 0:disabled 1:RD-penalty 2:maximum
Default: 0
--no-tskip Disable intra transform skipping
--tskip Enable intra transform skipping
Default: Enabled
--no-tskip-fast Disable fast intra transform skipping
--tskip-fast Enable fast intra transform skipping
Default: Enabled
--no-strong-intra-smoothing Disable strong intra smoothing for 32x32 blocks
--strong-intra-smoothing Enable strong intra smoothing for 32x32 blocks
Default: Enabled
--no-constrained-intra Disable constrained intra prediction (use only intra coded reference pixels)
--constrained-intra Constrained intra prediction (use only intra coded reference pixels)
Default: Disabled

Slice decision options:
--refresh Intra refresh type - 0:none, 1:CDR, 2:IDR (default: CDR)
Default: 1
-i/--keyint Max intra period in frames
Default: 0
--open-gop Only use intra for very first picture
Default: Disabled
--rc-lookahead Number of frames for frame-type lookahead (determines encoder latency)
Default: 10
-b/--bframes Maximum number of consecutive b-frames (now it only enables B GOP structure)
Default: 0
--bframe-bias Bias towards B frame decisions
Default: 0
--no-weightp Disable weighted prediction in P slices
-w/--weightp Enable weighted prediction in P slices
Default: Disabled
--no-weightbp Disable weighted (bidirectional) prediction in B slices
--weightbp Enable weighted (bidirectional) prediction in B slices
Default: Disabled

QP and rate distortion options:
-q/--qp Base QP for CQP mode
Default: 32
--cbqpoffs Chroma Cb QP Offset
Default: 0
--crqpoffs Chroma Cr QP Offset
Default: 0
--no-rdoq Disable RDO quantization
--rdoq Enable RDO quantization
Default: Enabled
--no-rdoqts Disable RDO quantization with transform skip
--rdoqts Enable RDO quantization with transform skip
Default: Enabled
--no-signhide Disable hide sign bit of one coeff per TU (rdo)
--signhide Hide sign bit of one coeff per TU (rdo)
Default: Enabled

Loop filter:
--no-lft Disable Loop Filter
--lft Enable Loop Filter
Default: Enabled

Sample Adaptive Offset loop filter:
--no-sao Disable Sample Adaptive Offset
--sao Enable Sample Adaptive Offset
Default: Enabled
--sao-lcu-bounds 0: right/bottom boundary areas skipped 1: non-deblocked pixels are used
Default: 0
--sao-lcu-opt 0: SAO picture-based optimization, 1: SAO LCU-based optimization
Default: 1

SEI options:
--hash Decoded Picture Hash SEI 0: disabled, 1: MD5, 2:
CRC, 3: Checksum
Default: 0

[DarrellS]

Syntax: x265 [options] infile [-o] outfile
infile can be YUV or Y4M
outfile is raw HEVC bitstream

No infile stdin - ?

[tnti]

INFO (again):

Performance of Strongene Lentoid Decoder = very good
Performance of the modified MPC FLV Splitter = very good

Performance of Strongene MP4 Demuxer = poor
(easily detectable on a slow machine)

Performance of the Osmo4 Player = poor
(easily detectable on a slow machine)

That's all, folks.

how to declare a specific fps of HEVC in monogram flv mux
or set a specific fps for output in X265 settings
?

Stronggene muxing their hevc streaming by using Monogram flv mux

[El Heggunte]

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

how to declare a specific fps of HEVC in monogram flv mux
or set a specific fps for output in X265 settings
?

Stronggene muxing their hevc streaming by using Monogram flv mux

The Monogram FLV Muxer is not configurable.
So if you give it an input from the Lentoid HEVC Source Filter, you'll always get a 25-fps output, and AFAIK ffmpeg still cannot deal with HEVC in an FLV container --- therefore, ...

No infile stdin - ?

> could you please port the stdin and Avisynth support of x264 to x265?
> Because it's a matter of *usability* ---
> --- raw video files are HUGE, whereas stdin consumes no space and
> Avisynth scripts are tiny.
>

Patches welcome for either of these. stdin support should be simple,
avisynth less so but not that difficult.

[Jacobr]

So I've been trying to build my own GUI and then ran into a few problems.

I am trying to do [generate avs]->y4m->[hm10+aac(or mp3 or whatevah)]->mp4/mkv
So far only mp4 path works fine

i can't find a way to mux hevc into flv or *avi* from command line in a way that would make it readable for mkvmerge. Right now i still have to avi mux manually from graphstudio and then i can remux subs and all things to form final mkv with merge. the avi mux stage is really the only thing that is left to do .
also, since im so used to matroska, id appreciate any help on muxing chapters and subs to mp4 with mp4 box

[enim]

For those who wanna HEVC In-Sight ITU H265 recommendations (still draft not yet finalized). But, definitely veryuseful guide-line for all x265 contributors. I am waiting for my 16 core dual CPU on my desk before I read.

[vhelp]

can someone post a new home for these x265.exe builds ? i have no more internet access and my work internet blocks everything. all i have right now is the old x265.exe app to test or play with. thank you.

[Trepack]

can someone post a new home for these x265.exe builds ? i have no more internet access and my work internet blocks everything. all i have right now is the old x265.exe app to test or play with. thank you.

As you know which one that is not blocked at work?

[vhelp]

just about all outside websites are blocked, for varous filter reasons, warz, virus, etc. purposes. i was fortunate to get this forum board unblocked, but i don't know for how long that will last. i can d/l from this site when i select the "direct liink" option when its available, but that's about it. pictures and images don't show on this boards either, they are blocks. my firm is working hard to block everything that does not relate their buisness. sorry to get too detailed about it here, just thought that others are probably in the same situation. anyway. don't sweat it, it will turn, i will wait till things work out. keep up the good work, thank you.

[Trepack]

Try the attached file rename it to .7z

[vhelp]

that one worked for me. it went through, at least this time. thanks!

edit: i resolved my issue with internet at home, problem is resolved, can d/l at home again..thanks Trepack for helping.

[Trepack]

Up-to-date whit commit 26c84a6


x265 encoder version 0.3+333-26c84a647f51

@Vhelp

Attached file rename it to .7z

[DarrellS]

that one worked for me. it went through, at least this time. thanks!

edit: i resolved my issue with internet at home, problem is resolved, can d/l at home again..thanks Trepack for helping.

That's good to know.

[Jacobr]

Is there any way then to do what i said, or is muxing to avi and then mkv from cmdline for now impossible?

[El Heggunte]

Is there any way then to do what i said, or is muxing to avi and then mkv from cmdline for now impossible?

For now, yes it's still impossible. For the notes, the Directshow filters CAN be called via command-line: dsmux.exe for example, is a CLI for Haali's Matroska Muxer. Two problems though: 1) it uses only Haali's muxer, and 2) certainly Haali's muxer doesn't support HEVC + most probably it also dislikes VfW-in-Matroska.

P.S.: you can go straight to MKV if you use the MPC-HC/BE Matroska Muxer (included in its standalone filters's package),
there really is no need for an intermediate AVI file anymore