[HEVC] x265.EXE: mingw builds

[LigH.de]

Hmm, the bugged parsing of Y4M headers should be fixed already? Probably patch 6528 (c688c11a0f12) y4m: fix copy-paste bug in range checks

[El Heggunte]

......

[DarrellS]

@DarrellS: using raw input instead of y4m should work

Not sure what you mean by using raw input. I've tried using uncompressed avi and y4m. It fails on all my bat files. I figured the y4m bat file should work since it's the last step before feeding to x265.exe but it fails.

MPC-HC has no problem playing the y4m file and Virtualdub has no problem reading the file but x265.exe can't read the y4m file (or the uncompressed avi).

[DarrellS]

OK, I finally got a bat file to work by re-encoding the avi file to something that x265.exe could read. It's encoding at 0.14fps though so I think I'll just stick with Virtualdub to run my tests. This way, I don't have to create any intermediate files or create bat files to produce those bat files and can just load any file I want in Virtualdub and run it though "-" to get a finished hevc.mkv.

[Selur]

Not sure what you mean by using raw input.

RAW = not wrapped in a y4m container. Like raw Yv12.

[LigH.de]

Version 0.8+251-ae07405973b7 encodes well again. But briefly after, an assembler code patch (6634) used a 64-bit only symbol. Therefore, from version 0.8+255-c4ea6cffe2b3 on, Win32 compilation will be broken until the assembler code is made 32-bit compatible.

[El Heggunte]

Version 0.8+251-ae07405973b7 encodes well again. But briefly after, an assembler code patch (6634) used a 64-bit only symbol. Therefore, from version 0.8+255-c4ea6cffe2b3 on, Win32 compilation will be broken until the assembler code is made 32-bit compatible.

The patch written by nabajit works

Quote of the day:

[DarrellS]

Not sure what you mean by using raw input.

RAW = not wrapped in a y4m container. Like raw Yv12.

I tried using ffdshow Raw video and got error from x265 that it couldn't decompress the file. The file that I thought I was able to encode was corrupt too so it looks like I have to use Virtualdub for high resolution files since that is what it feeds the encoder. Raw Video.

We ran into this problem a couple of weeks ago where the encoders couldn't handle high resolution (4K). I don't remember exactly what frame size that each encoder was limited to. It was higher than 3200x1800 but lower than 4k resolution. The standard resolution for 4k is 4096x2160.

[DarrellS]

[*] Beginning dub operation.
[i] Dub: Input (decompression) format is: XRGB8888.
[i] Dub: Output (compression) format is: YUV420.
[i] VideoEnc: yuv [info]: 4096x2160 fps 25000/1000 i420 unknown frame count

[i] VideoEnc: x265 [info]: HEVC encoder version 0.8+258-7ce180ca05b3
[i] VideoEnc: x265 [info]: build info [Windows][GCC 4.8.1][64 bit] 8bpp
[i] VideoEnc: x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[i] VideoEnc: x265 [info]: Main profile, Level-5 (Main tier)
[i] VideoEnc: x265 [info]: WPP streams / pool / frames : 68 / 4 / 2
[i] VideoEnc: x265 [info]: CU size : 32
[i] VideoEnc: x265 [info]: Max RQT depth inter / intra : 1 / 1
[i] VideoEnc: x265 [info]: ME / range / subpel / merge : dia / 25 / 0 / 2
[i] VideoEnc: x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 0
[i] VideoEnc: x265 [info]: Lookahead / bframes / badapt : 10 / 4 / 0
[i] VideoEnc: x265 [info]: b-pyramid / weightp / refs : 1 / 0 / 1
[i] VideoEnc: x265 [info]: Rate Control / AQ-Strength / CUTree : CQP-21 / 0.0 / 0
[i] VideoEnc: x265 [info]: tools: cfm esd rd=3 lft
[i] VideoEnc: encoded 750 frames in 158.39s (4.74 fps), 348.83 kb/s

[i] VideoEnc:
[i] VideoEnc: x265 [info]: frame I: 3 Avg QP:18.00 kb/s: 27103.00
[i] VideoEnc: x265 [info]: frame P: 148 Avg QP:21.00 kb/s: 991.48
[i] VideoEnc: x265 [info]: frame B: 599 Avg QP:22.75 kb/s: 56.05
[i] VideoEnc: x265 [info]: global : 750 Avg QP:22.39 kb/s: 348.83
[i] VideoEnc: x265 [info]: consecutive B-frames: 0.7% 0.0% 0.0% 0.7% 98.7%

[i] Mux: mkvmerge v6.8.0 ('Theme for Great Cities') 32bit built on Mar 2 2014 21:27:07
[i] Mux: 'F:\Temp 3\HEVC\Test-El Heggunte-64-258.mkv.hevc': Using the demultiplexer for the format 'HEVC/h.265'.
[i] Mux: 'F:\Temp 3\HEVC\Test-El Heggunte-64-258.mkv.hevc' track 0: Using the output module for the format 'HEVC/h.265 (unframed)'.
[i] Mux: The file 'Test-El Heggunte-64-258.mkv' has been opened for writing.
[i] Mux: Progress: 79%
[i] Mux: Progress: 100%
[i] Mux: Progress: 100%
[i] Mux: The cue entries (the index) are being written...
[i] Mux: Muxing took 0 seconds.[*] Ending operation.

The file size was smaller than the others at 1.26MB and 346Kbps.

[El Heggunte]

Hmmm, FWIW --- over here, version 0.8+258 was able to read a 4096x2160 y4m input
(through avs2yuv) and encoded all frames properly

[LigH.de]

I tried using ffdshow Raw video and got error from x265 that it couldn't decompress the file.

I don't understand what you mean. ffdshow is a DirectShow filter, usually only used in DirectShow based media players. What do you do to use ffdshow to write a *.yuv file? Or ... what file is x265 trying to "decompress"?
__

x265 0.8+259-dd189fd26f47 uses the assembler register fix and compiles in all interesting flavours (my 32-bit builds are XP compatible).

[vhelp]

cmd /C avs2yuv.exe g:\video.avs - | x265.exe --preset ultrafast --input-res 720x480 --fps 23.976 --frames 100 --crf 17 --input - -o video.hm10

when cmd /c is incorporated into the script, the whole process is a success--the video is encoded.
but without it, the encoder gives the error "no such option: --preset" ... for any of the encoder parameters written.

since no one else asked, i thought i would, thus....so, whats the story behind some of us needing the cmd /c and others not needing it ?

[LigH.de]

The question is where this command line is called.

If you are in a command line interpreter (like cmd.exe; also in a batch file), the whole command line is interpreted, and possible adjacent calls of commands or programs, separated by pipes or redirectors, are detected and handled.

If you are in a miscellaneous application (like VirtualDub), it probably executes a simple shell function which expects only one single program to be executed, and its name has to be the first parameter in the whole command line. Such a shell function is not able to concatenate calls of two programs with a pipe. Therefore you have to call the command line interpreter "cmd.exe" as the one program to be executed (to "wrap" the piping of two programs in only one program call), and the whole rest of this command line are the parameters to be handled by cmd. The first parameter "/c" tells cmd.exe then to interpret all the following parameters as if they were typed in a command line – and quit afterwards (in contrast to "/k", which waits for you to type "exit" after executing the rest of the parameters as interpreted command).

[vhelp]

so then, anyone using the example (or similar) is post # 1452 in their encoding (batch or dos window or gui) has to use cmd /c in there or else it will not work. at least that is my understanding and explains why the encoder via avs2yuv -> x265 fails (in windows xp, but not sure if in win7 is affected) and explains why we need to enter as { cmd /c -> avs2yuv -> x265 } for it to work.

in my gui i have to include the cmd /c for it to work or else i get the error mentioned.

does windows 7 have this problem ?
or, is this isolated to when you use avs2yuv because of how it works ?

[Selur]

I can call the above in a (C++) program without any 'cmd /c' on Windows XP, 7 and 8 without a problem.
(did a quick test a few minutes ago; normally I would split the two calls into two threads and connect the output of the first with the second)
-> it all depends on the environment you use and how you use it

[LigH.de]

@ vhelp:

Once again: It depends on the environment the command is called in.

If you type it into the command line directly or run it in a batch file, "cmd /c" is not required.

If the calling program uses Windows API functions (e.g. ShellExecuteEx(), which is able to monitor the started process and wait for its termination), then "cmd /c" is required because only a single program can be startet, not two at the same time. Piping between two programs is only interpreted inside a command line interpreter, not in a Windows function, therefore you have to execute the command line interpreter "cmd.exe" as wrapper when calling this line from within a Windows application.

It doesn't matter if you try that in Windows 7, 8, Vista, XP, or even 98.
__

@ Selur:

You claim to be able to run this command "interpreted". So which function did you use, and how?

A simple ShellExecute call would probably look similar to (..., 'cmd', '/c avs2yuv.exe ... | x265.exe ...', ...); you see that the whole command is split into the one program being executed (cmd, the command line interpreter), and the whole rest of the parameters being attached as command to be interpreted by it.
__

@ vhelp again:

Instead of cmd, you could also execute:

avs4x265.exe --preset ultrafast --frames 100 --crf 17 -o video.hm10 g:\video.avs

Only one program is called from within e.g. VirtualDub, so you don't need to wrap it inside a cmd call (avs4x265 calls x265 by itself, and generates all required parameters, so you don't have to type the dimensions and fps, they are read from the AviSynth output). Much shorter, much more elegant, and easily understandable. At least for me...

[vhelp]

ok, i found the test folder from the last time i was trying to get avs4x265 working. and this is where i was last stuck at when i gave up, using this version tool date 10/26/2013 7:32pm .

avs4x265.exe --preset ultrafast --frames 100 --crf 17 -o video.hm10 video.avs

x265: unrecognized option `--preset'
avs [error]: Error occurred while writing frame 0
(Maybe x264_64.exe closed)[/code]

[vhelp]

ok, thanks to google, i found this version, 0.2 and is working: http://kurtnoise.free.fr/x265/

however, at the bottom of the finished encode is this AVS error message...not sure why it comes up:

encoded 100 frames in 25.70s (3.89 fps), 587.71 kb/s
                                                                                
x265 [info]: frame I: 1      Avg QP:14.00  kb/s: 40.47   
x265 [info]: frame P: 20     Avg QP:13.40  kb/s: 1257.58 
x265 [info]: frame B: 79     Avg QP:14.80  kb/s: 425.05  
x265 [info]: global : 100    Avg QP:14.51  kb/s: 587.71  
x265 [info]: consecutive B-frames: 4.8% 0.0% 0.0% 4.8% 90.5% 
avs [error]: Error occurred while writing frame 104
(Maybe x264_64.exe closed)

[DarrellS]

Well crap, I forgot I could use the external encoder to create the y4m file instead of using ffdshow vfw RAW encoder.

Creating a .333 fps uncompressed 10 frame avi in GMG (which only takes a few seconds), converting it to 25fps uncompressed 20 GB avi in Virtualdub (takes about 20 minutes), using avs2yuv to create the y4m file (takes another 20 minutes) and using x265.exe to create a hevc file at less tha 3 fps.

or input the 10 frames into Virtualdub at .333 fps and set framerate conversion to 25 fps and use the external encoder to create a hevc.mkv that will play in MPC-HC all in one step.

don't understand what you mean. ffdshow is a DirectShow filter, usually only used in DirectShow based media players. What do you do to use ffdshow to write a *.yuv file? Or ... what file is x265 trying to "decompress"?

ffdshow has vfw encoders for saving RAW avi (and other) in Virtualdub. x265 was trying to open the raw avi that Virtualdub created.


The whole idea (for me anyway) for getting stdin "-" was so that we did not have to create all the huge intermediate files (raw yuv.avi or y4m) and could just convert the input avi (or any other video file we chose) to hevc.mkv or mp4 in one step in programs like Virtualdub, Hybrid or any other program that could use x265.exe via stdin.

Rewrote all my scripts to use modern settings and got everything working in Windows 7. I had to install 64bit MPC-HC to play the mkv that had stopped playing in the 32bit player. It was strange that they would play the hevc file created by running the bat file but stopped playing all of my mkv.

I've pretty much got Windows 7 set to where I want it but I can't find a way to get the codec and other video columns working in classic shell explorer (It took me years to figure out how to get it working in XP). I guess MS took the column handlers out of Vista and later builds so custom columns can no longer be used. There are around 300 useless columns that MS thinks you might need in Windows 7 but no useful video columns and the propertiesplus program that I used to replace the default properties menu won't work on 64bit either.

If MS would've fixed XP Pro 64 bit instead of building the POS Vista then there would be no reason to ever give up XP since the only good thing about Windows 7 is being able to access more memory. It takes all of the memory that XP was limited too just to run Windows 7 though so you can pretty much write off multitasking unless you 8 GB or more memory.

[Selur]

@LigH:

You claim to be able to run this command "interpreted". So which function did you use, and how?

I use the Qt frameworks QProcess. I guess it wraps everything needed, basically I use:

QProcess* myProcess = new QProcess();
myProcess->start("command line call");

But, like I wrote, I normally wouldn't do it all in one thread, I would split it into two threads, decoder and encoder separated and connect these threads, since that allows to differentiate if the decoder or the encoder crashes.

Cu Selur

[DarrellS]

LigH.de:
C:\Tools\x265>x265.exe --preset ultrafast --q 21 --input "input.y4m" --output "output.hevc" & mkvmerge.exe --default-duration 0:24fps "output.hevc" -o "C:\Tools\X265 Encoders\X265_64-bit\output.mkv"
y4m [info]: 4096x2160 fps 25/1 i420 frames 0 - 749 of 750
x265 [info]: HEVC encoder version 0.8+266-3f27daf35506
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
x265 [info]: encoded 750 frames in 283.44s (2.65 fps), 360.49 kb/s, 1.30 MB, Bit rate: 343 Kbps

Chromashift:

C:\Tools\x265>x265.exe --preset ultrafast --q 21 --input "input.y4m" --output "output.hevc" & mkvmerge.exe --default-duration 0:24fps "output.hevc" -o "C:\Tools\X265 Encoders\X265_64-bit\output.mkv"
y4m [info]: 4096x2160 fps 25/1 i420 frames 0 - 749 of 750
x265 [info]: HEVC encoder version 0.8+268-261b3c2e788e
x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
x265 [info]: encoded 749 frames in 422.33s (1.77 fps), 360.90 kb/s, 1.30 MB, Bit rate: 343 Kbps

Europe:

C:\Tools\x265>x265.exe --preset ultrafast --q 21 --input "input.y4m" --output "output.hevc" & mkvmerge.exe --default-duration 0:24fps "output.hevc" -o "C:\Tools\X265 Encoders\X265_64-bit\output.mkv"
y4m [info]: 4096x2160 fps 25/1 i420 frames 0 - 749 of 750
x265 [info]: HEVC encoder version 0.8+264-03bad90e94ad
x265 [info]: build info [Windows][GCC 4.6.3][64 bit] 8bpp
x265 [info]: encoded 750 frames in 276.33s (2.71 fps), 360.49 kb/s, 1.30 MB, Bit rate: 343 Kbps

[Selur]

I had to install 64bit MPC-HC to play the mkv that had stopped playing in the 32bit player. It was strange that they would play the hevc file created by running the bat file but stopped playing all of my mkv.

I use MPC-HCs 32bit nightly builds to playback mkv(hevc) files.
---

btw. did anyone bother to check if the defaults changed with the introduction of the latest new x265 options?

[LigH.de]

@ DarrellS:

I do not add any extra options to optimize speed. It's all plain compiling. Congratulations belong to the GCC developers, for making a pretty good compiler, and to the x265 developers, for supporting it well.
__

@ vhelp:

avs4x265 did not expect that x265 would close after encoding 100 frames.

You should possibly rather use a Trim() inside the AviSynth script, than limiting the encoder. A copy of a script doesn't take much space (just a 4 KB cluster).

[Gravitator]

Hi,
Will approved photo format based on H.265 - what is known?
(or is it still needs the blessing of the media mafia)
--------
Is there a right of project x265 provide impetus to the implementation of this format?
To give encoder/decoder (software/hardware) for developers of applications for smartphones/phototechnique

[LigH.de]

1. You mean like WebP vs. WebM (based on VP8/VP9)?
__

P.S.:

I repacked my x265 builds, they are now only "merge with stable" steps, but each contain all four flavours (Win32/Win64, 8bpp/16bpp) in archive friendly subdirectories.

[El Heggunte]

I repacked my x265 builds, they are now only "merge with stable" steps, but each contain all four flavours (Win32/Win64, 8bpp/16bpp) in archive friendly subdirectories.

Thanx 4 that, post #1 has been updated with the shorter URL

...........
Building for Win32, you may enable WinXP compatibility in CMake-gui; building for Win64, you should certainly not.

BUT according to what Steve Borho told me 3 days ago,

Strangely enough, I found that MinGW builds for Win64 run a lot faster when targeted for XP, so I would like to leave that as the default.

0_o

[LigH.de]

Therefore, using the reprogrammed Condition Variables (from the x264 sources) is now the default for all recent builds (Win32 as well as Win64). You don't need to build with "-DWINXP_SUPPORT" to have the binaries use the "reinvented wheels".

But "-DWINXP_SUPPORT" also makes the linker flag them to require at least Windows 5.x (XP), which makes little sense for 64-bit builds, because Windows XP 64-bit was very exotic; even Windows Server 2003 64-bit was not the most commonly used variant with this kernel.

It should not hurt to enable it, but it won't help a relevant number of users.

[El Heggunte]

Version 0.9 is out *_*

[DarrellS]

LigH.de
C:\Tools\x265>x265.exe --preset ultrafast --q 21 --input "input.y4m" --output "output.hevc" & mkvmerge.exe --default-duration 0:24fps "output.hevc" -o "C:\Tools\X265 Encoders\X265_64-bit\output.mkv"
y4m [info]: 4096x2160 fps 25/1 i420 frames 0 - 749 of 750
x265 [info]: HEVC encoder version 0.9+2-eef9a0050728
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 8bpp
encoded 750 frames in 288.22s (2.60 fps), 360.50 kb/s, 1.30MB, Bit rate: 343 Kbps

El Heggunte
C:\Tools\x265>x265.exe --preset ultrafast --q 21 --input "input.y4m" --output "output.hevc" & mkvmerge.exe --default-duration 0:24fps "output.hevc" -o "C:\Tools\X265 Encoders\X265_64-bit\output.mkv"
y4m [info]: 4096x2160 fps 25/1 i420 frames 0 - 749 of 750
x265 [info]: HEVC encoder version 0.9+2-eef9a0050728
x265 [info]: build info [Windows][GCC 4.8.1][64 bit] 8bpp
encoded 749 frames in 295.51s (2.53 fps), 360.91 kb/s, 1.30MB, Bit rate: 343 Kbps

[El Heggunte]

0.9+9-8273932bc5b7