[HEVC] x265.EXE: mingw builds

[El Heggunte]

...... I also tried adding "--input-res 628x514 --fps 25".

628 is not divisible by 8.
514 is not divisible by 8.
So you should use Avisynth for cropping or/and adding borders

Apparently, and different from x264, x265
(AND/OR some/all of the decoders currently available)
still cannot handle uncommon frame dimensions properly

I was wrong :–/ I've tried both commit fef74c2 and commit 4c618e3 on a 628x514 AVS file, and there are no visible artifacts in both encodes. So the actual problem probably is in the command-line options that Gomorrite keeps hiding from us

[Selur]

wild guess: --aq-mode X + --rdo Y with X > 0 and Y <2
btw. current presets are out of sync with the now changed defaults,.. (also attached a purposed fix)

[tnti]

@easyfab: Not working, tried different compilers, always get:

cmake -G "Unix Makefiles" -DCMAKE_TOOLCHAIN_FILE=cross-toolchain.cmake ../../source 
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: compiler
CMake Error: your CXX compiler: "compiler" was not found.   Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Check for working CXX compiler: compiler -- broken
CMake Error at /Applications/CMake 2.8-12.app/Contents/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
  The C++ compiler "compiler" is not able to compile a simple test program.

  It fails with the following output:

   

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:9 (project)


CMake Error: your CXX compiler: "compiler" was not found.   Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
-- Configuring incomplete, errors occurred!

tried:


SET(CMAKE_C_COMPILER /usr/bin/clang)
SET(CMAKE_CXX_COMPILER compiler /usr/bin/clang++)

SET(CMAKE_C_COMPILER /usr/bin/cc)
SET(CMAKE_CXX_COMPILER compiler /usr/bin/c++)

SET(CMAKE_C_COMPILER /usr/bin/gcc)
SET(CMAKE_CXX_COMPILER compiler /usr/bin/gcc++)

Your compiler environment problems
Others build environment produced another look?
G+ + issues

[Selur]

Builds fine on Mac Mavericks (-> https://forum.videohelp.com/threads/359995-Looking-for-x265-compiles-for-Mac-OSX-10-6)
I could compile it on different Debian derivatives without a problem, but no-go on Mac OS X 10.6.8 (Snow Leopard).
I tried the Linux and the XCode way, both failed + since I'm not really used to work on Mac OS X and the instructions are not really detailed regarding Xcode and Mac OS in general it might be, that the whole thing is just me.
-> if someone is able to build x265 on Mac OS X 10.6.8, I would be happy to know how.

[Jacobr]

i don't check the devs mailinglist too often, so for now just wanted to confirm that also for me --aq-mode 1 on veryslow and placebo will always produce visible and prevalent artifacts throughout the whole encode, unless im using full RDO analysis with --rd 2. I encoded short 1080p sample and lower res and always the same result. Using the latest 10.11 build

no problems:

x265 --crf 18 -F4 --preset veryslow --aq-mode 1 --rd 2 --rc-lookahead 30 -o output.hvc

many problems:

x265 --crf 18 -F4 --preset veryslow --aq-mode 1 --rd 1 --rc-lookahead 30 -o output.hvc

the rest of settings may vary, though i find greater lookaheads crashing my encodes if i try it with large enough res

[vhelp]

i keep seeing the -F usage in these discussions. and i wonder if part of the problems is because of incorrect usage. on my amd dual core (2 threads) 2gig ram cpu, i see no difference, be it in quality or encoding speed. anyway, sometimes i see it with and without a space in these discussions.

can someone confirm correct usage ?

-F1 or -F 1
-F2 or -F 2
-F3 or -F 3
-F4 or -F 4
-F5 or -F 5
-F6 or -F 6
-F7 or -F 7
-F8 or -F 8

[tnti]

i keep seeing the -F usage in these discussions. and i wonder if part of the problems is because of incorrect usage. on my amd dual core (2 threads) 2gig ram cpu, i see no difference, be it in quality or encoding speed. anyway, sometimes i see it with and without a space in these discussions.

can someone confirm correct usage ?

-F1 or -F 1
-F2 or -F 2
-F3 or -F 3
-F4 or -F 4
-F5 or -F 5
-F6 or -F 6
-F7 or -F 7
-F8 or -F 8

New X265 for this parameter is automatically adjusted


You can refer to the x265 Evaluators Guide 11-07-13.pdf

[vhelp]

unfortunately, that document is not accurately specifing correct (syntax) usage.
it refers to (-F) as the parameter and then documents the usage as -F5 and without a space between -F and 5 in the example. therefore, i am still left confused.

edit: nevermind. i see the document clearly says, "range of values :>=0" on page 4.

** thus, there should be a space between the parameter -F and value 5 for example **

so, the param being specified in these posts (w/out space between param and value) are wrong, and is probably the cause of some faulty results being posted here.

[tnti]

-F 2
The correct approach

[Selur]

"-F <integer>", better: "--frame-threads <integer>"

[Jacobr]

---

** thus, there should be a space between the parameter -F and value 5 for example **

so, the param being specified in these posts (w/out space between param and value) are wrong, and is probably the cause of some faulty results being posted here.

out of all things ?
So for the sake of compliance i switched to the correct approach with space and... yes, no change whatsoever
I mean, if i've been checking the info output of x265, it all looked alright and parser seemed to understand that apparently wrong param use, then what is the difference ? I saw how the setting worked and it seems that putting that space doesn't change a single thing in both info output of x265 and results of my testing (see prev post and the one before). Still issues with higher lookaheads (crashes) and frame parallelism with slower presets and higher res's, also --aq-mode 1 thing holds too (artifacts).

will upload test encodes, probably tomorrow unfortunately

[vhelp]

i hear you. working with this parameters can be very troublesome and fustrating at times.

sometimes it works (playback) and sometimes not. in the case of the --rc-lookahead i attribute the cause being the number of frames encoded because when change that number, the video plays back--its hit or miss.

to determine success of these encodes, i use MPC-BE as my main testbed of hevc playback. when that fails, then i fall back to the osmo4 player since the "test" video(s) will sometimes play only in that player.

so, it seems what we really need is a "play anything" or xH265 codec because most of these hevc encoded videos are still non-standard and we need to be able to play back the video no matter what the standard is in a given x265.exe hevc encoded video. we need a codec that will play always and without being so strict. othewise, we are lead to belive that our params are at fault or the current x265.exe build is borked in those instances.

[Selur]

anything the reference decoder can handle should be HEVC compliant

[vhelp]

i went from 0.5+256 to 0.5+257 but --preset is not working. same with 0.5+259 both not working.

edit: false alarm, it was my fault. all is working.

[vhelp]

so, i was having trouble with playback when using latest builds. was using 0.5+256 for last few days then just updated to 0.5+256/257 and they are not playing back all test encode parameters. not sure how far back these issues stem from, however, i did test with 0.5+131 and all the tough non-playables are playing fine in mpc-be.

one of the presets i was testing these on were ultrafast and slow, but mainly testing ultrafast for obvious reasons. and in the 0.5+256 if i threw anything greater than 100 frames, i would have playback problems. however, in 0.5+131 older build, playback was successful.

the complete parameters used in all these test encodes (100 frames or greater) are the ones below. what was causing the playback issues past 100 frames was when using these params: --rd 2 --b-adapt 1 --bframes 1 --aq-mode 1 --rc-lookahead 30 in the 0.5+256 build, but bumping back to 0.5+131 build, all the playback problems went away.

x265_0.5+131-f7e55b468373

--preset ultrafast --input-res 720x480 --fps 23.976 --frame-skip 0 --frames 300 --q 17 --rd 2 --b-adapt 1 --bframes 1 --aq-mode 1 --rc-lookahead 30 --input - -o "g:\video.hm10"

the moral of all this, is that when testing all the builds that we keep a detail track of each build that successfully works from encoding parameters to playback. when something works, successfully, keep that as a reference guage for future generation problem solving that you can verify against. 0.5+131 is a good example of this.

[x265]

i keep seeing the -F usage in these discussions. and i wonder if part of the problems is because of incorrect usage. on my amd dual core (2 threads) 2gig ram cpu, i see no difference, be it in quality or encoding speed. anyway, sometimes i see it with and without a space in these discussions.

can someone confirm correct usage ?

-F1 or -F 1
-F2 or -F 2
-F3 or -F 3
-F4 or -F 4
-F5 or -F 5
-F6 or -F 6
-F7 or -F 7
-F8 or -F 8

Technically, the correct syntax includes a space between the option and the value being passed with that option. In practice, the code that x265 uses to parse the command-line input is fairly tolerant, and it does its best to figure out what you meant. So, as you can see, either way works.

You will see the number of frame threads in this line of x265's command-line output:
x265 [info]: WPP streams / pool / frames : 17 / 8 / 3

Tom

[x265]

...
the moral of all this, is that when testing all the builds that we keep a detail track of each build that successfully works from encoding parameters to playback. when something works, successfully, keep that as a reference guage for future generation problem solving that you can verify against. 0.5+131 is a good example of this.

If you use the --csv option, you will generate comma-separated value log files that include your command-line syntax, the encoding results and a record of the build version #.

Tom

[vhelp]

any suggestions on how to retain grain ?

i'm working on some dark scenes, and in the original analog lossless captures, the grain is more detailed than they are in my hdpvr captures. so far i'm not having any luck.



i am using these params.

[Selur]

any suggestions on how to retain grain ?

don't use x265


btw. got a question about one off the new vbv parameters:
'--vbv-maxrate <integer>' Max local bitrate (kbit/s) <- is this really the max local bit rate? (it isn't in x264, which is why I ask)

[vhelp]

actually, i wasn't having trouble with grain since all my sources were hdpvr based to date. however, when i opened an old analog avi capture from one of my older cards, it had the grain. i had forgotten about it, (the grain) being used to the hdpvr's simple capture method, which happens to remove most of the grain. i just didn't pay attention to it since. then today, i attempted to see if i could retain it via hevc by tuning the params somewhat but i guess it is still too early for grain retention.

[Jacobr]

build 0.5+259-9d74638c3640 ( csv is a nice option, thx for reminding ) [ earlier aq capable too ]

--crf 18 -F 4 --preset slow --aq-mode 1 --rd 2

slower / lookahead changes = same results
to clarify, problems with rc-look weren't with playing back, i don't have issues to play back virtually anything i am able to finish encoding. The thing is with like 1620p and slower and lookahead > 30, yea, encode won't finish.

Caution these are raw streams

[Gomorrite]

628 is not divisible by 8.
514 is not divisible by 8.
So you should use Avisynth for cropping or/and adding borders

Apparently, and different from x264, x265
(AND/OR some/all of the decoders currently available)
still cannot handle uncommon frame dimensions properly

I was wrong :–/ I've tried both commit fef74c2 and commit 4c618e3 on a 628x514 AVS file, and there are no visible artifacts in both encodes. So the actual problem probably is in the command-line options that Gomorrite keeps hiding from us

No, you were right. At least in my case changing the cropping in Avisynth solved the problem. Thanks.

[vhelp]

i'm sure some of you are aware of this, but just in case... ffmpeg 2.1 supports muxing hevc videos to an mkv container.

https://ffmpeg.org/
October 28, 2013, FFmpeg 2.1
We have made a new major release (2.1) It contains all features and bugfixes of the git master branch from 28th October. A partial list of new stuff is below:

- HEVC decoder, raw HEVC demuxer, HEVC demuxing in TS, Matroska and MP4

** how to mux hevc to mkv **

usage:

ffmpeg -i video.mp4 -vcodec copy -acodec copy -y h:\video.mkv

[Selur]

is there also a new video bitstream filter to allow raw .265 input?

[vhelp]

i was not able to get the muxing to TS working. my current hevc decoder does not like it from ffmpeg 2.1 oh well. i was just testing the muxing feature.

is there also a new video bitstream filter to allow raw .265 input?

do you mean, serving, as source to be encoded ? as in input.265 -> hevc.hm10 ?

don't know. does l-smash support hevc yet ? maybe through that method. haven't tried it.

[Selur]

do you mean, serving, as source to be encoded ?

no, I ment a raw stream, instead of a stream inside a MP4-container

don't know. does l-smash support hevc yet ?

according to the commit-list: yes, but I haven't tried.

[vhelp]

actaully, that's what i meant, raw stream, encoded to hevc.hm10 not hevc.hm10 -> hevc.mp4

i tried it with l-smash but it doesn't work. gives me the error: "[Fatal]: Failed to avformat_open_input."

  v = "video.hm10"                            # raw stream
  LoadPlugin( "C:\PLUGINS\LSMASHSource.dll" ) # <-- version 8,230KB 8/30/2013 11:45AM
  LWLibavVideoSource(v, cache=true , seek_mode=0 ).selectevery(2,0)

[vhelp]

on another note.. i also noticed something different in decoder quality: ffplay vs mpc-be, in dark scenes giving "green" patchy artifacts {like the one in post # 888 if you YUV enhance it--i can't do it manually since i don't know the avs script command to unduce it}

ffplay - cleaner, no green artifacts
mpc-be - green patchy parts in certain areas

[El Heggunte]

.......

ffplay - cleaner, no green artifacts
mpc-be - green patchy parts in certain areas

That's interesting, and suggests that the MPC-BE developers are NOT using the ffmpeg/libav code correctly

OTOH, why not use LAV Video, or the Lentoid decoder, instead of MPC-BE's built-in video decoder

[El Heggunte]

--- SNIPP ---
No, you were right. At least in my case changing the cropping in Avisynth solved the problem. Thanks.

Sín embargo, I didn't have to use mod-8 resolutions to make x265 encode properly with a "non-complex" command-line.

Therefore, I am two-times right, and you are two-times wrong