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 22nd July 2016, 19:11   #4021  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 290
I've attached workaround for 32-bit GCC (it sets "-march=pentium4 -mtune=generic" as default for 32-bit GCC).

To apply this patch in x265 folder you can:
save attached '32bit.txt' to x265 source file folder on your HDD;
from x265 folder you can execute:
patch -p1 <32bit.txt
exclusive or (if you don't have patch command):
hg import --no-commit 32bit.txt

To clean x265 source code (from this patch for example) you can execute:
hg update -C
Attached Files
File Type: txt 32bit.txt (626 Bytes, 15 views)
Ma is offline   Reply With Quote
Old 23rd July 2016, 04:40   #4022  |  Link
divxmaster
Registered User
 
Join Date: Mar 2015
Location: New Zealand
Posts: 45
Quote:
Originally Posted by gamebox View Post
@divxmaster: Thanks for sharing your experience with pre-sharpening. I've browsed the complete list of AviSynth sharpening plugins/scripts, and will test some to see the results on both sharpening and resulting bitrate (whether image complexity increases as well). For now, "adaptive" sharpening seems to me as the most appropriate direction to go. I've started using Lanczos4resize which improves sharpness (though it introduces halo as well, unlike Lanczos3). Also, decreased deblock from -1 to -2, and am currently testing -3 as image quality improved after I discarded qg size 16 parameter and artifacts stopped "accumulating" in smaller image blocks containing sharp, pronounced details where they were overly visible.

I compress using modified "slower" profile - me star, subme 7, rd 6, ref 6, bframes 9, aq-mode 2/strength 2, psy rd 2, psy rdoq 1, no rskip, rect, no sao, no strong intra smoothing. Speedup options are limit modes, limit refs 3, no weightb, no amp, max merge 2.
@gamebox, have you tried using vapoursynth64 instead of avisynth? its much faster. sharpening options seem limited though. Best seems to be awarpsharp2, but this is the only dll I cannot get to work at all in vapoursynth. off to the forums I suppose. back on topic, I see you use bframes 9, I seem to remember reading anything over 5 is pointless. this may have changed.
divxmaster is offline   Reply With Quote
Old 23rd July 2016, 06:42   #4023  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,300
Quote:
Originally Posted by Ma View Post
The 32-bit version hangs. It was reported some time ago https://bitbucket.org/multicoreware/...-x265-hangs-at

Solution for 32-bit GCC 6.1:
Is this an issue for GCC 5.3 too?

x265 2.0+9-2737c6ff5f80 was built with an older MSYS/MinGW package by XhmikosR.
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 23rd July 2016, 08:05   #4024  |  Link
Ma
Registered User
 
Join Date: Feb 2015
Posts: 290
Quote:
Originally Posted by LigH View Post
Is this an issue for GCC 5.3 too?

x265 2.0+9-2737c6ff5f80 was built with an older MSYS/MinGW package by XhmikosR.
GCC 5.3 works OK. The problem is with stack alignment. In Windows and ancient CPU the stack alignment was 4 which is too small for SSE2 functions. GCC needs to analyze code and realign the stack in functions that calls SSE2 functions -- GCC 6.1 works wrong in this area.

If I add option '-mincoming-stack-boundary=2' to encoder/slicetype.cpp in 32-bit GCC 6.1, it works without '-march' option. I need some time to detailed analyze...

By the way, if you add line in your build script:
export CXXFLAGS="-march=pentium4 -mtune=generic"
before part that build 32-bit x265, it will be much faster version of 32-bit x265.
Ma is offline   Reply With Quote
Old 23rd July 2016, 09:00   #4025  |  Link
gamebox
Registered User
 
Join Date: Nov 2011
Posts: 66
@divxmaster: Using more than 6 B-frames indeed gives little benefit, in my experience only about 2-3% of B-frame "rows" contain 7 frames, for example. But, I also haven't noticed any significant speedup reducing B-frame count to 6, and that's the reason I kept it at 9 - for medium/low bitrate encoding any improvement counts.

I've tested many sharpening filters yesterday and discarded Adaptive Sharpen, as it smooths out less pronounced details slightly. The best combination I've come up is Sharpen (AviSynth built-in filter) at value 0.2, followed by Msharpen at threshold 10 and strength 20. For the time being, performance of AviSynth is not an issue as my new octo-core AMD FX CPU "Bulldozes" through data quite nicely.
gamebox is offline   Reply With Quote
Old 23rd July 2016, 10:57   #4026  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 43
Hey,

somebody got a hint for me how to reduce the seek time in VLC?
I'm using Staxrip, x265 Main10 with OpenGOP deactivated. (No other settings)
katzenjoghurt is offline   Reply With Quote
Old 23rd July 2016, 10:59   #4027  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,520
tried vlc nightly? tried mkv as container?
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 23rd July 2016, 11:50   #4028  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 43
Quote:
Originally Posted by Selur View Post
tried vlc nightly? tried mkv as container?
Hey Selur,

I didn't try the VLC Nightly yet. Though neither MKV, MP4 nor using Handbrake instead of Staxrip seemed to make a real difference.
The only thing that helped was deactivating OpenGOP... But I still got seek times of roundabout 5sec with a 1080p video on my Xeon 1241v3.
katzenjoghurt is offline   Reply With Quote
Old 23rd July 2016, 12:06   #4029  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,435
Quote:
Originally Posted by katzenjoghurt View Post
Hey Selur,

I didn't try the VLC Nightly yet. Though neither MKV, MP4 nor using Handbrake instead of Staxrip seemed to make a real difference.
The only thing that helped was deactivating OpenGOP... But I still got seek times of roundabout 5sec with a 1080p video on my Xeon 1241v3.
Have you tried lowering the keyframe value during encoding?
froggy1 is offline   Reply With Quote
Old 23rd July 2016, 12:07   #4030  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 5,520
Quote:
The only thing that helped was deactivating OpenGOP...
I thought you already had it deactivated, since you wrote:
Quote:
I'm using Staxrip, x265 Main10 with OpenGOP deactivated. (No other settings)
-> try the nightly, it should work with opengop deactivated.
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 23rd July 2016, 12:46   #4031  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 4,968
Quote:
Originally Posted by Selur View Post
-> try the nightly, it should work with opengop deactivated.
and activated. It always worked with deactivated.

Make sure StaxRip isn't outdated, older mp4box had some nasty bugs.
sneaker_ger is offline   Reply With Quote
Old 23rd July 2016, 12:50   #4032  |  Link
littlepox
Registered User
 
Join Date: Nov 2012
Posts: 214
--keyint 150

This shall help you with the seek time

ps, try MPC-HC 64bit. Currently LAV 64bit is the most efficient decoder.

Last edited by littlepox; 23rd July 2016 at 12:59.
littlepox is offline   Reply With Quote
Old 23rd July 2016, 14:29   #4033  |  Link
katzenjoghurt
Registered User
 
Join Date: Feb 2007
Posts: 43
Ahh... thx guys.

The VLC Nightly helped... as did the --keyint 150 parameter.


Quote:
Originally Posted by Selur
I thought you already had it deactivated, since you wrote:
I had it activated... I was just still not happy with the result.
katzenjoghurt is offline   Reply With Quote
Old 23rd July 2016, 15:04   #4034  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 795
To whom this may interest:

I've decided to share my new (MSYS2-based) MinGW_w64 toolchain.
The directory includes CMake, Git and Mercurial.

https://www.mediafire.com/?3ib29yauv5kdw

NOTICE:

when calling the .SH scripts, you (may) need to add a ./ to the command-line —

for example, "./multi64.sh" instead of simply "multi64.sh".

Last edited by filler56789; 23rd July 2016 at 15:11. Reason: clarification
filler56789 is offline   Reply With Quote
Old 26th July 2016, 00:01   #4035  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 162
the GCC 6.1.0 x64 build of 2.0+9 seems to be much faster than GCC 5.3.0 x64.
jlpsvk is offline   Reply With Quote
Old 26th July 2016, 07:03   #4036  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,300
Hard to believe if >90% of the relevant code is in assembler, optimized for several different levels of supported instruction set extensions. Without details and numbers, "much faster" won't mean anything.
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th July 2016, 07:50   #4037  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 162
Command:
Code:
--crf 20 --output-depth 10 --level-idc 5.1 --cbqpoffs -3 --min-keyint 23 --keyint 240 --no-open-gop --colorprim bt709 --colormatrix bt709 --transfer bt709 --rskip --crqpoffs -3 --high-tier
GCC 5.3.0 - 9.82fps average
GCC 6.1.0 - 12.28fps average

Movie - Batman v Superman.

The rest is the same: StaxRip, DirectShowSource, LAV filters CPU decoding, Core i7-4790K CPU, 8GB RAM, Windows 7 x64.

OK... taking back..... Now realised,that I haven't turned on --me star, like with GCC 5.3.0. Running new test.

Last edited by jlpsvk; 26th July 2016 at 07:58.
jlpsvk is offline   Reply With Quote
Old 26th July 2016, 07:52   #4038  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,300
Wow... and which CPU, which instruction sets reportedly used?
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 26th July 2016, 08:02   #4039  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 162
LigH, as i wrote...running new test with --me star, as wih GCC 5.3.0... So will report new speed then.

Code:
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
PS: What is the benefit os ME STAR over default ME in MEDIUM?
jlpsvk is offline   Reply With Quote
Old 26th July 2016, 08:13   #4040  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,300
The search for motion vectors in different ME modes is more or less exhaustive; "star" will probably prefer vertical and horizontal directions, but won't search as far in diagonal directions, I believe. I never saw descriptive diagrams yet, though... But fewer directions means faster speed, obviously.
__________________

German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 20:37.


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