x265 HEVC Encoder

[sneaker_ger]

x265 library/cli doesn't offer HDR->SDR conversion by itself. You can do it using other software, e.g. ffmpeg or VapourSynth and then feed that to x265 (or use the x265 integrated in ffmpeg).

https://forum.doom9.org/showthread.php?t=175125
https://forum.doom9.org/showthread.php?p=1800675
https://github.com/ifb/vapoursynth-tonemap/

[enctac]

Originally Posted by enctac

Problem about x265 2.7+17 and L-SMASH r1459/r1450
...

Result

x265 2.7+14 -> No problem.

x265 2.7+17 -> muxer.exe freeze or crash.

Which is wrong ? x265 ? or L-SMASH ?

Originally Posted by LigH

Let's check the last 3 commits ... which may be the most probable: 5be53f0 (Clean up SEI::write function)? Sounds like it changed the output in important values.

x265 2.7+17 outputs broken SEI. (maybe SEIuserDataUnregistered, extra 16bytes)
Not only 2pass encoding.
Need to fix this.

Left side: 2pass encoding
Right side: 1pass encoding

[LigH]

I already mentioned that in the x265 developer mailing list. Maybe you would like to register there as well and attach your report.

[enctac]

OK, I sent a mail.

[Boulder]

Originally Posted by Sp00kyFox

qg-size 8 pretty much fixes it. this also slightly increased the bitrate.

It seems to increase the bitrate quite a lot. I just tested on a 4000-frame 720p encode:

qg-size 64 : 3147,41 kbps
qg-size 32 : 3648,01 kbps
qg-size 16 : 3954,23 kbps

Didn't test qg-size 8 yet.

Average QP is about the same, a little bit less than 21.

[Ashok Kumar Mishra]

Originally Posted by enctac

Problem about x265 2.7+17 and L-SMASH r1459/r1450

L-SMASH : https://github.com/l-smash/l-smash
r1459 binary : http://www.mediafire.com/file/b7w5m1...9_20180310.zip

x265 2.7+14-d7c26df32fae:[Windows][MSVC 1913][64 bit] 8bit+10bit+12bit
x265 2.7+17-2e370d98c806:[Windows][MSVC 1913][64 bit] 8bit+10bit+12bit

sample.avs
#---
ColorBarsHD(1280,720).Trim(0,500).ConvertToYV12()
ShowFrameNumber(scroll=true,size=128)
#---

ffmpeg.exe -i sample.avs -f yuv4mpegpipe - | x265.exe --y4m - --pass 1 --bitrate 1000 -o sample.265
ffmpeg.exe -i sample.avs -f yuv4mpegpipe - | x265.exe --y4m - --pass 2 --bitrate 1000 -o sample.265

muxer.exe -i "sample.265"?fps=30000/1001 -o sample.mp4

Result

x265 2.7+14 -> No problem.

x265 2.7+17 -> muxer.exe freeze or crash.

Which is wrong ? x265 ? or L-SMASH ?

Thank you for reporting this bug. We are fixing it.

[Sp00kyFox]

Originally Posted by Boulder

It seems to increase the bitrate quite a lot. I just tested on a 4000-frame 720p encode

how does it visually compare? (inb4: well ok, more bitrate is probably gonna look better) I would think at 720p or even SD a smaller qg-size is even more important since the situation demonstrated in the clip I uploaded is even more likely to appear. from what I've tested edges and details when adjacent to flat areas become more refined with lower qg-size.

[Boulder]

Didn't do any visual comparisons with those ones yet. I'll now run a 2-pass encode with all four values, using the lowest bitrate (3147 kbps) for all of them as the average bitrate and see how they look. Previously when I just tested changing qg-size and kept all the rest the same, qg-size 32 looked best compared to the original frame (least distortion) on a frame-by-frame comparison.

[microchip8]

my experience with qg-size on movies (full hd) is that the lower it is, the more fine detail it preserves but also increases ringing around smaller objects. the higher it is, the more smoother the picture and also the less ringing you get. i keep mine at 32 most of the time

[Sp00kyFox]

wanted to let you know that my first conclusion was overhasty. seems the artifacts were caused by aq-motion. theoretically this options seems to be a nice idea but the approach can cause problem with this kind of scene where you have some small moving details that get crippled by this option. qg-size 8 counteracts that but the result is still worse than the default qg-size 32 without aq-motion. I'm doing some more comparisons regarding qg-size wihout aq-motion this time.

edit: well after further tests I can say qg-size 32 is a good default value. SSIM-wise it seems to be the best choice for general content. in the scene I provided earlier qg-size 64 is little bit too smooth while 32 gives a good balance. 16 and 8 both produce noticeable artifacts.

[Barough]

x265 v2.7+19-1fafca24a399 (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Boulder]

Originally Posted by Sp00kyFox

edit: well after further tests I can say qg-size 32 is a good default value. SSIM-wise it seems to be the best choice for general content. in the scene I provided earlier qg-size 64 is little bit too smooth while 32 gives a good balance. 16 and 8 both produce noticeable artifacts.

Yes, I agree that the default 32 is a good choice. Fortunately so, as the 25% bitrate increase from the smaller values was a bit steep

[enctac]

Don't use 2.7+15 - 2.7+19.
2.7+14 maybe safe.
We should wait until developers fixes SEI bug.

Originally Posted by enctac

Result

x265 2.7+14 -> No problem.

x265 2.7+17 -> muxer.exe freeze or crash.

Which is wrong ? x265 ? or L-SMASH ?

Originally Posted by enctac

x265 2.7+17 outputs broken SEI. (maybe SEIuserDataUnregistered, extra 16bytes)
Not only 2pass encoding.
Need to fix this.

Originally Posted by Ashok Kumar Mishra

Thank you for reporting this bug. We are fixing it.

[pradeeprama]

For the curious, of course we will be at NAB in Vegas from April 9th - 12th! We will be one of the demos at the MulticoreWare booth in SU-14708. If you want to discuss all things media, swing by the booth! Suggested topics include, but are certainly not limited to the soon-to-publish AVX512 acceleration, content adaptive optimizations for ABR encoding with x265, upcoming overhaul of AQ and associated visual improvements. or a request to take a selfie with the creators of the world’s most popular HEVC encoder.

See you in Vegas!

PS: Make sure to mention this post on doom9 if you stop by to stand a chance to win some open-source memorabilia!

[Midzuki]

x265.exe 2.7+20-3440a56acc78

fix bug in SEI::write clean up

https://forum.videohelp.com/threads/...09#post2516009

[Asmodian]

Midzuki, I get a report "Trojan:Script/Cloxer.A!cl" for that link and Windows 10 automatically deletes it. This is the first time I have had a warning from x265.exe, is it a false alarm?

[LigH]

Your antivirus (which?) probably caught a JavaScript related to advertizing in a forum site. It seems not to be related to the attached x265 build.

If you use NoScript and an ad blocker (like uBlock Origin) in your web browser, you will probably not get any advertizing network scripts confusing you before you even see the Video Help forum thread.

[Midzuki]

Originally Posted by Asmodian

Midzuki, I get a report "Trojan:Script/Cloxer.A!cl" for that link and Windows 10 automatically deletes it. This is the first time I have had a warning from x265.exe, is it a false alarm?

LigH answered well. I stopped using anti-virus software ages ago because 1) they became bloatware and 2) too many false positives.

Regarding browsers's add-ons: I use NoScript against most sites, but not against the ones I visit regularly (such as Doom9 and Videohelp). My HUGE hosts file is sufficient to block most /all ads on most sites, except on the anti-social networks (Twitter and Fakebook specifically).

TL; DR — Get rid of Windows 10, problem solved

P.S.: for what it's worth...... https://www.virustotal.com/#/file/1d...e336/detection

[LigH]

x265 2.7+20-3440a56acc78

fix bug in SEI::write clean up

[Barough]

x265 v2.7+22-946f82dbf4e8 (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default