x265 HEVC Encoder [Archive] - Page 41

MeteorRain

29th March 2015, 05:34

All files encoded by 444 and up don't play on LAV 0.64 with enabled CUDA decoding

Reproduced.

Would you please tell us how you produce the "MKV" file? From RAW output to MKV?

And could you please try to encode to MKV directly using my build (-full)? And also try to encode to MP4 directly using my build (-full) then remux into MKV?

As far as I can tell, it's due to the "MKV" part.

29th March 2015, 10:43

I also put my mod in my signature for those who want. Compiled with lavf and l-smash.

I decided to test new builds on 1080p file with my current settings.
Test file http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m

But there is a problem with yours build -- the result line your build outputs to stderr instead of normal stdout and I have no 2nd time of your build. You can see my test-park-1080p.bat (attached in 7z). Why are you changed this?

LoRd_MuldeR

29th March 2015, 14:47

But there is a problem with yours build -- the result line your build outputs to stderr instead of normal stdout

It's a common practice to write all textual output to the stderr stream, so that the stdout stream remains "clean" for piping the actual output data to the next process in the chain.

Imagine you would be running x265 to write the encoded H.265 bitstream to stdout, because you want to process the H.265 stream in another process, but then some status messages get "mixed" into the resulting stream... Bad idea :devil:

Ajvar

29th March 2015, 15:00

Reproduced.

Would you please tell us how you produce the "MKV" file? From RAW output to MKV?

And could you please try to encode to MKV directly using my build (-full)? And also try to encode to MP4 directly using my build (-full) then remux into MKV?

As far as I can tell, it's due to the "MKV" part.

Yes, I also noticed yesterday that RAW hevc plays fine. Also Win10 plays it fine too. But my main OS is Windows 7.
I used multiple mkv toolnix versions and result is the same.
EDIT: OK, i managed to mux in MP4 and it plays but... I will tet and describe everything in couple minutes.

29th March 2015, 16:54

It's a common practice to write all textual output to the stderr stream, so that the stdout stream remains "clean" for piping the actual output data to the next process in the chain.

Thanks for the info. I will rewrite my *.bat file (maybe original x265 will be print all text to stderr).

29th March 2015, 17:01

Can't mux in mp4, I am GUI guy and YAMB doesn't let me mux it for some reason.

I downloaded your mkv-file and remuxed to mp4
http://msystem.waw.pl/x265/445-bug.mp4

I don't have nVidia graphics card, so in my system all your files work.

Ajvar

29th March 2015, 17:22

I don't have nVidia graphics card, so in my system all your files work.

Yes, Did you notice that Mediainfo says that Heigh of mkv video is 1920x1088 instead of 1920x1080?
I also managed to mux to mp4 and then remux to mkv again and it now works... but I believe that is because after muxing to mp4 Heigh is fixed to 1080.
Now I have to understand why that happened and whose fault: mine, muxer or encoder.
EDIT: Also please check if RAW x265 file was chaged after muxing to mp4 (check checksumms).

29th March 2015, 17:34

Yes, Did you notice that Mediainfo says that Heigh of mkv video is 1920x1088 instead of 1920x1080?
I also managed to mux to mp4 and then remux to mkv again and it now works... but I believe that is because after muxing to mp4 Heigh is fixed to 1080.
Now I have to understand why that happened and whose fault: mine, muxer or encoder.

In my tests your original mkv file works, then I demuxed video and audio and muxed to mp4 -- it works too (1920x1088). But if I mux directly demuxed video & audio to new mkv file, it is only sound (not works). If I "add" to mmg.exe muxed mp4 file and save as new mkv file, everything is OK. Strange...

Ajvar

29th March 2015, 18:02

In my tests your original mkv file works, then I demuxed video and audio and muxed to mp4 -- it works too (1920x1088). But if I mux directly demuxed video & audio to new mkv file, it is only sound (not works). If I "add" to mmg.exe muxed mp4 file and save as new mkv file, everything is OK. Strange...

So such behavior may say that there is something with encoded file meaning the way it was encoded.
May I ask you to download original file (https://mega.co.nz/#!lVwiHbJD!FEJPulHQDK29diNhQPP9KFXy3SSFN5tKF1gg7i8CIJE) which is 1920x1080 and encode with the same settings I encode and tell me if such behavior persists (1920x1088 and mux troubles)? Something tells me that it might be due to --min-cu-size 16 because 16x68=1088 but perhaps that is just a shot in the dark.
--pmode --input - --input-res 1920x1080 --fps 30 --no-high-tier --min-cu-size 16 --no-open-gop --crf 22.7 --no-rdoq-level --no-psy-rdoq --vbv-maxrate 8000 --vbv-bufsize 8000 --deblock=-1:-1 --colormatrix bt470bg

29th March 2015, 18:49

May I ask you to download original file (https://mega.co.nz/#!lVwiHbJD!FEJPulHQDK29diNhQPP9KFXy3SSFN5tKF1gg7i8CIJE) which is 1920x1080 and encode with the same settings I encode and tell me if such behavior persists (1920x1088 and mux troubles)?

I downloaded and encoded via MeGUI. Result http://msystem.waw.pl/x265/t.7z

MediaInfo shows 'Height' 1088 and 'Original height' 1080.

Ajvar

29th March 2015, 18:58

I downloaded and encoded via MeGUI. Result http://msystem.waw.pl/x265/t.7z

MediaInfo shows 'Height' 1088 and 'Original height' 1080.

Yep, thank you very much. Problem found: if you set --min-cu-size 16 then frame size will be scewed (1088 instead of 1080) and that will bring a crash on LAV 0.64 if file encoded by x265 1.5+444 and up.

WOW! That was very tricky to find. Not sure if it is a bug or just evolution of x265 encoder/LAV decoder.

sneaker_ger

29th March 2015, 19:26

Ajvar

29th March 2015, 22:13

I think it's a bug in mkvmerge. I will make a report.

/edit:
reported: https://github.com/mbunkus/mkvtoolnix/issues/1152

/edit2:
Mosu has fixed the issue for mkvtoolnix 7.9.0. You can test the pre-version:
https://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ (687 or newer)

Yes, thank you, I would never report this bug in such way with documentation and formulas.
It really fixed MediaInfo information about Height, but funny or not, it still crashes my player the same way if I mux in mkv, but plays fine if I mux in mp4:)

Even more! As I see those crashes have nothing with min-cu-size 16 because I just tested it with both settings! It is another bug in MkvToolnix because if I remux streams from affected video file or encode directly to MP4 and then remux to MKVToolnix (direct drop MP4 into the window) then and only then it works!

This is just hilarious. I spent all day, found 2 bugs in 2 different software (forced --min-cu-size 16 instead of 8 in Hybrid and crop in mkv toolnix) but STILL suffer from crashes by unidentified bug!:scared:
Samples here (https://mega.co.nz/#!NRAjjYrB!GVTsic5cED4lwXxIf8J334AmJVCPOirYRa-5EYrsNhE): working MP4 with LAV 0.64-CUDA and 2 non-workiing MKV with min blocks 8 and 16.

Long story short: encodes by x265 >=1.5+444 muxed in MKV will crash trying to play with LAV 0.64 and CUDA decoding.
And could you please try to encode to MKV directly using my build (-full)?
As far as I can tell, it's due to the "MKV" part.

Could you please give me command line for that so I would just edited source?

29th March 2015, 22:29

Long story short: encodes by x265 >=1.5+444 muxed in MKV will crash trying to play with LAV 0.64 and CUDA decoding.

It could be quite simple bug in mkvmerge -- you can try add "--no-info" option to x265 parameters and maybe there will be no crash (I guess).

Ajvar

29th March 2015, 23:41

It could be quite simple bug in mkvmerge -- you can try add "--no-info" option to x265 parameters and maybe there will be no crash (I guess).

I found it. It's about setting vbv-max rate.
This line works fine:
x265 --preset slower --pools 8 --pmode --pme --input - --input-res 1920x1080 --fps 30 --no-high-tier --merange 58 --no-open-gop --keyint 300 --bframes 7 --crf 22.7 --qpfile GENERATED_QP_FILE --psy-rd 0.5 --psy-rdoq 1 --deblock=-1:-1 --output "T:\Temp\output.265"
This crashes.
x265 --preset slower --pools 8 --pmode --pme --input - --input-res 1920x1080 --fps 30 --no-high-tier --merange 58 --no-open-gop --keyint 300 --bframes 7 --crf 22.7 --qpfile GENERATED_QP_FILE --psy-rd 0.5 --psy-rdoq 1 --vbv-maxrate 8000 --vbv-bufsize 8000 --deblock=-1:-1 --output "T:\Temp\output.265"
And all became after 444+ encoder.
Now WHY is that? - That's the question. 439 is OK, 444 is NOT so it's narrow window.
HOW is that connected with LAV 0.64 with CUDA decoding - that's too. But this may be not the only symptom.
WHY only MKV but MP4 plays fine? - another mystery.
But I finally found this bug and... feel stupid that spent so much time on it:) But if it will be fixed, I will feel somewhat better:)
Here are samples, check yourself (https://mega.co.nz/#!wdJhjJzK!KqDAg8_4D3PYz8Fe7AYl14etbVugYIOcLheb7MZRfjM).

sneaker_ger

29th March 2015, 23:55

I think Ma was hinting at the size of the custom SEI x265 writes. With more parameters (esp. long ones like --vbv) it becomes longer and maybe it triggers a crash in LAV/CUVID because of that. Try to recreate your latest crash sample but with "--no-info". Either way, it's unclear where the bug is. Since it crashed in the Nvidia software I think they are to blame.

Ajvar

30th March 2015, 00:38

It could be quite simple bug in mkvmerge -- you can try add "--no-info" option to x265 parameters and maybe there will be no crash (I guess).

I think Ma was hinting at the size of the custom SEI x265 writes. With more parameters (esp. long ones like --vbv) it becomes longer and maybe it triggers a crash in LAV/CUVID because of that. Try to recreate your latest crash sample but with "--no-info". Either way, it's unclear where the bug is. Since it crashed in the Nvidia software I think they are to blame.

Emm, it worked! It. Really. Worked!:thanks:

Now I go sleep, too tired

LazyNcoder

30th March 2015, 00:55

MeteorRain

30th March 2015, 01:22

Could you please give me command line for that so I would just edited source?

You can try

x265-Xbit-full -o test.mkv source.mkv --YOUR --OTHER --PARAM --HERE

- or, use -

-o test.mp4

to produce MP4 files.

This way it'll use Haali MKV Muxer / L-SMASH MP4 Muxer to mux your hevc data on the fly when writing files.

You can also use --opts 1 to skip writing all the param string into hevc header and still keep the SEI segment, While the --no-info option will completely remove the SEI.

I suspect that there's still a bug inside mkvmerge.

30th March 2015, 06:13

Emm, it worked! It. Really. Worked!:thanks:

Now I go sleep, too tired

Mkvmerge add extra one SEI if mux raw HEVC stream, not add extra one if remux from MP4. x265 1.5+444 gives longer SEI (because --rdoq-level and deblock). If longer SEI is doubled, it crash with nVidia decoder.

My software LAV decoder stop working with your example after the SEI was tripled -- in your original MKV it was doubled, I demux video track and mux again to MKV (2 + 1 = 3).

Workaround to this mkvmerge bug: first mux to MP4 and then to MKV not works with large files -- I try with 6 GB HEVC stream and mkvmerge crashes when remuxing from MP4.

If you take v1.hevc file with nonempty SEI and execute:
mkvmerge -o v2.mkv v1.hevc
mkvextract tracks v2.mkv 0:v2.hevc
mkvmerge -o v3.mkv v2.hevc
mkvextract tracks v3.mkv 0:v3.hevc
mkvmerge -o v4.mkv v3.hevc
mkvextract tracks v4.mkv 0:v4.hevc
mkvmerge -o v5.mkv v4.hevc
mkvextract tracks v5.mkv 0:v5.hevc
mkvmerge -o v6.mkv v5.hevc
mkvextract tracks v6.mkv 0:v6.hevc
...

The number of SEI in the files should be equal the number in filename.

MeteorRain

30th March 2015, 10:24

Guys let me get this straight. 10bit videos bring better color range(like, they remove banding) but they make the details/quality lower at the same bitrate as 8bit vids. Am I right?
I mean, encoder has to store 10bit pictures in same size/bitrate as 8bit pictures.
I did two encodes, one was x265 8bit version and the other was 10bit. it looks like the 10bit version could use a little higher CRF/bitrate to look the same as 8bit version.

Also, Noob question, what is the difference between main 10 profile and 10bit encoder? isn't it better just to use main 10 profile instead of 10bit encoder?

Higher precision leads to less quality loss. 10bit encoding uses 25% more bitrate to store the same amount of pixels, but the benefits are more than 25% so that if you decrease the bitrate to the same level (thus higher CRF), it should still maintain better quality.

At least this is true on x264. With x265 there are still rooms for improvement. Let's see.

To your second question. Main10 is a profile that also covers lower profile such as Main. It's the highest complexity a video can be. Thus with Main profile, the video can only be 8 bit, while with Main10, it can be 8 up to 10 bit. And with the coming Main 12 profile, it can be 8 up to 12 bit.

stax76

30th March 2015, 10:25

I released a new beta version with some video encoder improvements and made a snapshot of both the help page and the code file that contains the defaults so later I can use a diff tool to catch all changes.

Added GUI for NVEncC (tool for NVIDIA H.264/H.265 GPU encoding)
Added GUI for QSVEncC (tool for Intel Quick Sync H.264 GPU encoding)
Added x265 option --pools
Added x265 option --frame-threads
Added x265 option --min-cu-size
Added x265 option --log-level frame and updated help for --log-level
Updated x265 to version 1.5+370
Updated QSVEncC (tool for Intel H.264 GPU encoding) to version 1.32

http://sourceforge.net/projects/staxmedia/?source=navbar

LazyNcoder

30th March 2015, 10:51

Higher precision leads to less quality loss. 10bit encoding uses 25% more bitrate to store the same amount of pixels, but the benefits are more than 25% so that if you decrease the bitrate to the same level (thus higher CRF), it should still maintain better quality.

At least this is true on x264. With x265 there are still rooms for improvement. Let's see.

To your second question. Main10 is a profile that also covers lower profile such as Main. It's the highest complexity a video can be. Thus with Main profile, the video can only be 8 bit, while with Main10, it can be 8 up to 10 bit. And with the coming Main 12 profile, it can be 8 up to 12 bit.
Thanks a lot.

so, using main 10 profile is better than forcing the video to be 10bit(for lower crf/bitrate videos). Am I right?

I released a new beta version with some video encoder improvements and made a snapshot of both the help page and the code file that contains the defaults so later I can use a diff tool to catch all changes.

Added GUI for NVEncC (tool for NVIDIA H.264/H.265 GPU encoding)
Added GUI for QSVEncC (tool for Intel Quick Sync H.264 GPU encoding)
Added x265 option --pools
Added x265 option --frame-threads
Added x265 option --min-cu-size
Added x265 option --log-level frame and updated help for --log-level
Updated x265 to version 1.5+370
Updated QSVEncC (tool for Intel H.264 GPU encoding) to version 1.32

http://sourceforge.net/projects/staxmedia/?source=navbar

Correct me if I'm wrong. since v1.5 of x265, --aq-mode 1 is default. but in StaxRip it's still --aq-mode 2. I mean you can only change it to --aq-mode 1 or 0 or default which is --aq-mode 1. so no --aq-mode 2 until you write it in "Custom Switches".
Selecting auto-variance removes the --aq-mode switch and let the encoder uses the default value which is not auto-variance.

LigH

30th March 2015, 10:57

Another weekly, stable merge build.

x265 1.5+448-22a312799bb0 (GCC 4.8.2 EXE + DLL) (https://www.mediafire.com/download/auas2wib54x9nxi/x265_1.5+448-22a312799bb0.7z)
x265 1.5+448-22a312799bb0 (GCC 4.9.2 UPX-EXE) (https://www.mediafire.com/download/ogq99y9vl285w0y/x265_1.5+448-22a312799bb0.GCC492.7z)

It seems that the x265 project will allow easier configuring for native architecture optimized builds. If I would enable this feature, my builds would probably still be generated for SSE2 or SSE3, using AMD K10 architecture (Phenom-II). I did not yet change my workflow.

stax76

30th March 2015, 11:37

@LazyNcoder

Thanks, I've missed it, here is a fix: https://www.dropbox.com/s/n5q0jhukdkrt6jm/StaxRip_2015.03.30.7z?dl=0

You should download EXE + DLL, drop the content in the x265 folder and run the batch file located in the x265 folder, I hope LigH unifies it.

MeteorRain

30th March 2015, 11:38

Thanks a lot.

so, using main 10 profile is better than forcing the video to be 10bit(for lower crf/bitrate videos). Am I right?

No it's not. Put 8 bit video inside Main 10 means you are driving away any decoders that can't properly decode 10 bit video. You are more likely "forcing a profile" in this situation.

It's like you are looking for a driver to drive a personal sedan car but claim to require a commercial driving license, thus kicking away those who don't have one, and it's unnecessary.

That's why we use the lowest profile that fits the video to increase compatibilities.

LigH

30th March 2015, 11:58

..., I hope LigH unifies it.

What do you want me to do? Please explain more verbosely.

The GCC 4.8.2 package contains both static EXE and DLL versions because the default scripts by Multicoreware create both. If you intend to use only the EXE, omit the DLL; the DLLs are included only for developers who prefer to link them instead of calling the EXE.

The GCC 4.9.2 package was compiled by the media-autobuild_suite which does not provide a DLL, only the EXE. I would not be able to change this script accordingly. Most GUI developers use the EXE only, anyway. I wonder if I should also disable UPX, the uncompressed EXE are easier to pack by 7-zip (more similarities among them).

stax76

30th March 2015, 12:41

What do you want me to do? Please explain more verbosely.

The GCC 4.8.2 package contains both static EXE and DLL versions because the default scripts by Multicoreware create both. If you intend to use only the EXE, omit the DLL; the DLLs are included only for developers who prefer to link them instead of calling the EXE.

The GCC 4.9.2 package was compiled by the media-autobuild_suite which does not provide a DLL, only the EXE. I would not be able to change this script accordingly. Most GUI developers use the EXE only, anyway. I wonder if I should also disable UPX, the uncompressed EXE are easier to pack by 7-zip (more similarities among them).

use identical folder and file names, StaxRip expects different names so I included a batch file everybody can use, expanding the batch file to handle both packages might also work, at the moment it looks like this:

Rename Win32_8bpp "32-Bit 8-Bit"
Rename Win32_16bpp "32-Bit 10-Bit"
Rename Win64_8bpp "64-Bit 8-Bit"
Rename Win64_16bpp "64-Bit 10-Bit"

sneaker_ger

30th March 2015, 12:54

Mkvmerge add extra one SEI if mux raw HEVC stream, not add extra one if remux from MP4. x265 1.5+444 gives longer SEI (because --rdoq-level and deblock). If longer SEI is doubled, it crash with nVidia decoder.[...]

I have written an answer in the the mkvtoolnix thread (http://forum.doom9.org/showthread.php?p=1715328#post1715328). We should take the discussion there, it's not a problem of x265.

Ajvar

30th March 2015, 22:58

You can try
x265-Xbit-full -o test.mkv source.mkv --YOUR --OTHER --PARAM --HERE
- or, use -o test.mp4 to produce MP4 files.
This way it'll use Haali MKV Muxer / L-SMASH MP4 Muxer to mux your hevc data on the fly when writing files.

You can also use --opts 1 to skip writing all the param string into hevc header and still keep the SEI segment, While the --no-info option will completely remove the SEI. I suspect that there's still a bug inside mkvmerge.
Thank's for sharing, will use it later. I believe this will be better than toolnix then.
I have written an answer in the the mkvtoolnix thread (http://forum.doom9.org/showthread.php?p=1715328#post1715328). We should take the discussion there, it's not a problem of x265.
You are like a moderator but better:) Taking all info, drying it out to get the most important and make right conclusions... and even continue digging, thank you! I see that mkvtoolnix' author is not going to change that, oh well... will mux in mp4 then or use direct mkv muxing as told above.

31st March 2015, 17:45

I made new fprofiled builds of 10-bit x265 and compare them to my normal build with "-O2 -march=corei7-avx" options.

Win7 64-bit, i5 3450S, test video http://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

Warriors:
x265-AVX -- compiled with options "-static -s -O2 -march=corei7-avx -mtune=corei7-avx"

x265-AVXp-O2 -- compiled with options:
"-static -s -O2 -march=corei7-avx -mtune=corei7-avx -fprofile-generate" for first pass
"-static -s -O2 -march=corei7-avx -mtune=corei7-avx -fprofile-use -fprofile-correction" for second pass

x265-AVXp-O3n -- compiled with options:
"-static -s -O3 -fno-tree-vectorize -march=corei7-avx -mtune=corei7-avx -fprofile-generate" for first pass
"-static -s -O3 -fno-tree-vectorize -march=corei7-avx -mtune=corei7-avx -fprofile-use -fprofile-correction" for second pass

Result:
x265-AVX | 413.45s | 1.22 fps | 100.0%
x265-AVXp-O2 | 408.58s | 1.23 fps | 98.8%
x265-AVXp-O3n | 409.15s | 1.23 fps | 99.0%

Accuracy: +/- 1.23s = +/- 0.3%

Full result, builds and test.bat -- http://msystem.waw.pl/x265/test3.7z

x265_Project

31st March 2015, 18:01

Until now, HEVC has been a technology for experts and hard-core video enthusiasts only. We have a fast, reliable HEVC decoder, called UHDcode, but we needed to find a way to make this available for everyone to try. x265 was available in source code form, but we didn't have an application available directly from the x265 team.

To make it easier for anyone to try x265 and experience the benefits of HEVC, today we're launching the x265 HEVC Upgrade (https://x265.com). We've created a new Windows 64 bit application that lets you convert MP4 files to HEVC. There is a new Basic Mode which anyone non-technical person should be able to use. In Advanced Mode we expose the full feature set of x265.

The x265 Encoder application is bundled with our UHDcode HEVC decoder, packaged as a Windows DirectShow filter; a plug-in for Windows Media Player. This upgrades Windows Media Player (64 bit) to play back HEVC video files (raw bitstreams or MP4 files with HEVC).

The MSRP of the x265 HEVC Upgrade is $29.95, but for a limited time you can download for free at www.x265.com (https://x265.com). We hope you find these applications valuable.

stax76

31st March 2015, 19:17

How does the free download work?

benwaggoner

31st March 2015, 19:21

How does the free download work?
You need to set up an account, but don't need to give any financial information. Make sure to hit the "Apply Coupon" button (which has the code pre-filled) to make it $0.

Took me about 90 seconds from clicking the link to having it installed.

NikosD

31st March 2015, 19:37

x265_Project

31st March 2015, 19:39

I'm doing the procedure from the mobile phone and although it gave me a discount, it had already charged me with a quantity of 2, so I had to pay 29.95$

I cancelled the order and tried to put a new one with quantity 1, but there is no discount now.

I see no coupon.

Obviously I'm doing something wrong...
I'll PM you a link to the download and a key Nikos. For others... make sure your shopping cart has a quantity of 1 before you check out. The coupon code should be filled out already. The coupon code can only be used once by each person.

stax76

31st March 2015, 19:40

You need to set up an account, but don't need to give any financial information. Make sure to hit the "Apply Coupon" button (which has the code pre-filled) to make it $0.

Took me about 90 seconds from clicking the link to having it installed.

Try this kick as Firefox plugin, next time you might make 85. :D

https://addons.mozilla.org/en/firefox/addon/smartfill

Gravitator

31st March 2015, 19:54

This plugin supports playback of non-standard B16 frames?

stax76

31st March 2015, 20:04

@x265_Project

Which font size is the x265 GUI using? It looks like 7 which is kind of challenging for old man like me.

x265_Project

31st March 2015, 20:26

This plugin supports playback of non-standard B16 frames?
I don't know... you would have to try it. We test UHDcode against a wide range of spec-compliant HEVC bitstreams, but as far as I know, it is also designed to decode any bitstream regardless of whether it fits a legal profile (we don't ask questions, we just decode). Of course, our main objective is to make sure that any possible legal bitstream can be decoded quickly and accurately. We look forward to your feedback.

x265_Project

31st March 2015, 20:27

@x265_Project

Which font size is the x265 GUI using? It looks like 7 which is kind of challenging for old man like me.
I don't know. As you know, it's challenging to squeeze all the advanced options in a single UI. Expect ongoing improvement in this area.

LigH

31st March 2015, 22:24

Will this project still exist the day after tomorrow? ;) ;)

x265_Project

31st March 2015, 23:32

Will this project still exist the day after tomorrow? ;) ;)
Now why do you have to go and say a thing like that? You of all people. :)

Of course it will. The x265 HEVC Upgrade is a straightforward product that enables and delivers of two of our core technologies; x265 and UHDcode.

stax76

1st April 2015, 00:57

I don't know. As you know, it's challenging to squeeze all the advanced options in a single UI. Expect ongoing improvement in this area.

I know but for me it's different since my GUI is built from code (no form designer) resulting in not more then one option per "line" in most cases.

LigH

1st April 2015, 07:27

Just funny to see projects announced around the 1st of April. But okay, it appears to be more credible than systemd forking the Linux kernel (resistance is futile)...

LigH

1st April 2015, 09:38

Building x265 with GCC now supports STATIC_LINK_CRT to include minimal Windows GUI API support, as yet linked from the basic MSVCRT.DLL; would you rate this option useful / important / irrelevant? This DLL will probably be present in quite any Windows version, I believe; linking it statically may not be as important as when someone would compile using MS Visual Studio, but rather add redundant code to the distributed binaries, I guess?