Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 28th March 2018, 00:33   #5961  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
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/
sneaker_ger is offline   Reply With Quote
Old 28th March 2018, 08:15   #5962  |  Link
enctac
Registered User
 
Join Date: May 2017
Posts: 8
Quote:
Originally Posted by enctac View Post
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 ?
Quote:
Originally Posted by LigH View Post
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
Attached Images
 
enctac is offline   Reply With Quote
Old 28th March 2018, 08:25   #5963  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
I already mentioned that in the x265 developer mailing list. Maybe you would like to register there as well and attach your report.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 28th March 2018, 09:56   #5964  |  Link
enctac
Registered User
 
Join Date: May 2017
Posts: 8
OK, I sent a mail.
enctac is offline   Reply With Quote
Old 28th March 2018, 10:24   #5965  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by Sp00kyFox View Post
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 28th March 2018, 10:31   #5966  |  Link
Ashok Kumar Mishra
Registered User
 
Join Date: Feb 2018
Posts: 13
madVR

Quote:
Originally Posted by enctac View Post
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

Code:
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.
Ashok Kumar Mishra is offline   Reply With Quote
Old 28th March 2018, 12:05   #5967  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
Join Date: Aug 2007
Posts: 79
Quote:
Originally Posted by Boulder View Post
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.

Last edited by Sp00kyFox; 28th March 2018 at 13:12.
Sp00kyFox is offline   Reply With Quote
Old 28th March 2018, 13:47   #5968  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 28th March 2018, 17:50   #5969  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
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
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 28th March 2018, 18:40   #5970  |  Link
Sp00kyFox
Registered User
 
Sp00kyFox's Avatar
 
Join Date: Aug 2007
Posts: 79
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.

Last edited by Sp00kyFox; 29th March 2018 at 11:04.
Sp00kyFox is offline   Reply With Quote
Old 29th March 2018, 06:04   #5971  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v2.7+19-1fafca24a399 (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 29th March 2018, 09:15   #5972  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by Sp00kyFox View Post
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
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 29th March 2018, 10:27   #5973  |  Link
enctac
Registered User
 
Join Date: May 2017
Posts: 8
Don't use 2.7+15 - 2.7+19.
2.7+14 maybe safe.
We should wait until developers fixes SEI bug.

Quote:
Originally Posted by enctac View Post
Result
x265 2.7+14 -> No problem.
x265 2.7+17 -> muxer.exe freeze or crash.
Which is wrong ? x265 ? or L-SMASH ?
Quote:
Originally Posted by enctac View Post
x265 2.7+17 outputs broken SEI. (maybe SEIuserDataUnregistered, extra 16bytes)
Not only 2pass encoding.
Need to fix this.
Quote:
Originally Posted by Ashok Kumar Mishra View Post
Thank you for reporting this bug. We are fixing it.
enctac is offline   Reply With Quote
Old 30th March 2018, 06:42   #5974  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 48
NAB 2018, of course we will be there!

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!

Last edited by pradeeprama; 30th March 2018 at 10:13. Reason: typo
pradeeprama is offline   Reply With Quote
Old 30th March 2018, 17:33   #5975  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
x265.exe 2.7+20-3440a56acc78

fix bug in SEI::write clean up

https://forum.videohelp.com/threads/...09#post2516009
Midzuki is offline   Reply With Quote
Old 1st April 2018, 16:36   #5976  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
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?
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Old 1st April 2018, 16:48   #5977  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 1st April 2018, 19:04   #5978  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
Quote:
Originally Posted by Asmodian View Post
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
Midzuki is offline   Reply With Quote
Old 2nd April 2018, 12:39   #5979  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x265 2.7+20-3440a56acc78

fix bug in SEI::write clean up
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd April 2018, 12:47   #5980  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
x265 v2.7+22-946f82dbf4e8 (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:53.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.