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 4th April 2021, 08:49   #8081  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
If you need StaxRip specific help, better ask in the StaxRip thread...

In general: There is no magic. Preserving enough quality needs enough bitrate (1-pass CRF encoding will help here). The rest is avoiding more loss with wrong options... But this clip seems to be rather generic and without interlacing.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 4th April 2021, 11:38   #8082  |  Link
martinpickett
Registered User
 
Join Date: Jun 2020
Posts: 1
Quote:
Originally Posted by benwaggoner View Post
I wonder if I'll be looking at a Graviton2 equivalent workstation in a couple of years. There's not a lot of info about it for video encoding outside of this oddly specific post comparing H.264 encoding speeds between Graviton2 and Xeon 8-core instances. A 36% improvement in min/dollar isn't that impressive yet, and a comparison with an AMD instance might have gone the other direction.
I found this article from AnandTech illuminating in general. For specific video encoding data you have to look at the 525.x264_r benchmark in SPECint2017 covered on pages seven and eight.
martinpickett is offline   Reply With Quote
Old 4th April 2021, 14:56   #8083  |  Link
imhh11
Registered User
 
Join Date: Jul 2016
Posts: 171
Quote:
Originally Posted by DJATOM View Post
You can grab those optimized builds from my repo: https://github.com/DJATOM/x265-aMod/...s/tag/3.5%2B20
They are all in the 7z archive, since it's easier to upload stuff to github with single file.
Zen3 flags aren't present in gcc10 (but that available with gcc11), so no such build for now. I'll consider doing it when will buy 5950x.

PS: cpu-specific builds are 10-bits only, while generic is multilib.
Hi, thank you so much for doing this.
Which one should I get for Kaby Lake cpu ?
imhh11 is offline   Reply With Quote
Old 4th April 2021, 15:43   #8084  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by imhh11 View Post
Hi, thank you so much for doing this.
Which one should I get for Kaby Lake cpu ?
Skylake build
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 5th April 2021, 11:17   #8085  |  Link
abban270
Registered User
 
Join Date: Jan 2009
Posts: 6
Quote:
Originally Posted by LigH View Post
If you need StaxRip specific help, better ask in the StaxRip thread...

In general: There is no magic. Preserving enough quality needs enough bitrate (1-pass CRF encoding will help here). The rest is avoiding more loss with wrong options... But this clip seems to be rather generic and without interlacing.
ok i will post the same thread in staxRip section
and if you have try to re-encode this clip to x265 with good bitrate and small size dont forget to post the result
maybe i will take it
thanks
abban270 is offline   Reply With Quote
Old 5th April 2021, 21:20   #8086  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by martinpickett View Post
I found this article from AnandTech illuminating in general. For specific video encoding data you have to look at the 525.x264_r benchmark in SPECint2017 covered on pages seven and eight.
Thanks. And wow, Graviton2 is the winner for 16-core H.264 reference encoder perf! And also for x264 at 64vcpu. Of course, a Graviton2 vCPU is a full core and a Xeon/AMD is half of a SMT core. Still, very impressive!

IIRC, x264 has more even amounts of ARM and x86-64 SIMD optimization than x265, so x265 might not be as competitive yet. I'll try to get some tests run when I've got some time.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 7th April 2021, 15:48   #8087  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Fun with Yuuki-Asuna again:

Because version 3.5 is official, and I saw that the Yuuki branch had a lot of accepted commits 3 days ago, I decided to try to build a fresh clone in MSYS2/MinGW64 (MABS). But the first surprise I saw was the version number being calculated, so I stopped here...

Code:
-- x265 Release Version 2.3M+850-g2b25c9ba0+47
Please give some advice if/when/how there will be another chance to get it running again, with your help, and where to discuss that (probably better not here; possibly in msg7086's Issue tracker?)...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 9th April 2021, 10:19   #8088  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 478
Hey,

Could anyone point me to a "for dummies" guide to compiling x265 for Windows with gcc? I'm aware there's instructions on the x265 wiki, but... It looks like it's written for someone who is already very experienced with cross compilation, which unfortunately I'm not. I do have experience with general Linux use, so hopefully I would not need my hand held too much.

As for why I'm planning to cross compile... My objective is just to try out the new znver3 march option on my 5950X.

Thanks!
aegisofrime is offline   Reply With Quote
Old 9th April 2021, 10:41   #8089  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
My binaries were built on an MSYS2/MinGW basis of the "media-autobuild suite" under Windows, but with a small set of manually executed shell scripts in an interactive shell, derived from the "build/msys" templates provided by MultiCoreWare, which I may share, so you could adapt them with your specific compiler optimizations as env-vars.

But if you do so, don't be afraid of a plethora of NASM warnings not yet fixed...

Adapting these scripts for MinGW cross-compilation under a real Linux is also possible, I sometimes tried that in an Ubuntu MATE VM...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 9th April 2021, 12:14   #8090  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 377
I just built znver3 optimized binary using gcc10.3, you can get it here.
__________________
Me on GitHub
PC Specs: Ryzen 5950X, 64 GB RAM, RTX 2070
DJATOM is offline   Reply With Quote
Old 9th April 2021, 14:11   #8091  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 478
Quote:
Originally Posted by LigH View Post
My binaries were built on an MSYS2/MinGW basis of the "media-autobuild suite" under Windows, but with a small set of manually executed shell scripts in an interactive shell, derived from the "build/msys" templates provided by MultiCoreWare, which I may share, so you could adapt them with your specific compiler optimizations as env-vars.

But if you do so, don't be afraid of a plethora of NASM warnings not yet fixed...

Adapting these scripts for MinGW cross-compilation under a real Linux is also possible, I sometimes tried that in an Ubuntu MATE VM...
If you could share them that would be great!

Quote:
Originally Posted by DJATOM View Post
I just built znver3 optimized binary using gcc10.3, you can get it here.
If it's not too much trouble, could I request for a 12-bit build as well?
aegisofrime is offline   Reply With Quote
Old 9th April 2021, 14:37   #8092  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 377
Sure, link.
__________________
Me on GitHub
PC Specs: Ryzen 5950X, 64 GB RAM, RTX 2070
DJATOM is offline   Reply With Quote
Old 9th April 2021, 14:43   #8093  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 478
Much obliged, cheers!
aegisofrime is offline   Reply With Quote
Old 9th April 2021, 17:55   #8094  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
x265 multilib build script for x86-64 Windows EXE in media-autobuild suite's MSYS2/MinGW64 mintty shell

Configured for media-autobuild suite with ccache enabled. Naming is a bit historical, I have a few similar scripts with different content and architectures (also W32 and W32XP).

Results will remain in /build/x265_git-git/build/msys64_hdr10_ml/8bit in the MABS directory structure. This is for pure git sources from MultiCoreWare, without modifications.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 10th April 2021, 01:18   #8095  |  Link
eclipse98
1.16 MileHi
 
Join Date: Feb 2008
Location: Denver, CO
Posts: 26
Please help me understand what's going on here

Hi All,

Please help me understand what's going on here, because it does not quite compute.

Using a higher level (and slower) preset should, theoretically, result in:

1. Lower QP for the same bitrate.
2. Lower bitrate for the same QP.

Yet, results below on the same 2 min clip seem to contradict this assumption:

slow preset: encoded 7194 frames in 0:09:57.54 (12.04 fps), 5112.86 kb/s, Avg QP:33.05
slower preset: encoded 7194 frames in 0:37:57.12 (3.16 fps), 5515.60 kb/s, Avg QP:33.24
very slow preset: encoded 7194 frames in 1:20:43.82 (1.49 fps), 5440.53 kb/s, Avg QP:33.33

Compared to Slow preset, Slower and 'Very Slow' presets have both produced higher bitrate and higher QP.
Using default preset settings with '--crf 25 --no-sao', x265 3.4+70-aMod-gcc10.2.1 DJATOM Mod.

The only conclusion I can up with is that 'Avg QP' value is not to be trusted.

Cheers and thanks for your help!
eclipse98 is offline   Reply With Quote
Old 10th April 2021, 12:15   #8096  |  Link
LeXXuz
21 years and counting...
 
LeXXuz's Avatar
 
Join Date: Oct 2002
Location: Germany
Posts: 716
Quote:
Originally Posted by eclipse98 View Post
Hi All,

Please help me understand what's going on here, because it does not quite compute.

Using a higher level (and slower) preset should, theoretically, result in:

1. Lower QP for the same bitrate.
2. Lower bitrate for the same QP.

Yet, results below on the same 2 min clip seem to contradict this assumption:

slow preset: encoded 7194 frames in 0:09:57.54 (12.04 fps), 5112.86 kb/s, Avg QP:33.05
slower preset: encoded 7194 frames in 0:37:57.12 (3.16 fps), 5515.60 kb/s, Avg QP:33.24
very slow preset: encoded 7194 frames in 1:20:43.82 (1.49 fps), 5440.53 kb/s, Avg QP:33.33

Compared to Slow preset, Slower and 'Very Slow' presets have both produced higher bitrate and higher QP.
Using default preset settings with '--crf 25 --no-sao', x265 3.4+70-aMod-gcc10.2.1 DJATOM Mod.

The only conclusion I can up with is that 'Avg QP' value is not to be trusted.

Cheers and thanks for your help!
Without going into too much detail: from my experience WITH CRF; the higher the preset, the more detail will be preserved (at the same CRF level.)
=> Longer encoding time, bigger filesizes and higher quality of the output.

Last edited by LeXXuz; 10th April 2021 at 12:18.
LeXXuz is offline   Reply With Quote
Old 10th April 2021, 12:43   #8097  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Higher presets preserving more quality is only "true with constraints", more among the faster presets than among the slower ones ... a slower preset enables more elaborate features to search for "redundancies" (similarities useful to save space). If more can be found, chances are that the difference left is smaller, so the precision of difference encoding in P and B frames can be better. But doesn't need to, certainly; it is also possible that saving some additional data for these more elaborate features requires more space than without. At least it's quite probable that there need to be fewer intra encoded blocks, so the encoding can be more efficient, in general. Yet, in practice, most users won't need any slower preset than "slower". And "placebo" is certainly a waste of time and energy.

In addition, the target for the CRF mode is the "rate factor", a metric for the loss of quality. It is possible that the features enabled in a faster preset may return more efficient results for a specific video material than the enabled features of a slower preset. There are no guarantees.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 10th April 2021 at 12:49.
LigH is offline   Reply With Quote
Old 10th April 2021, 20:25   #8098  |  Link
eclipse98
1.16 MileHi
 
Join Date: Feb 2008
Location: Denver, CO
Posts: 26
Quote:
Originally Posted by LigH View Post
Higher presets preserving more quality is only "true with constraints", more among the faster presets than among the slower ones ... a slower preset enables more elaborate features to search for "redundancies" (similarities useful to save space). If more can be found, chances are that the difference left is smaller, so the precision of difference encoding in P and B frames can be better. But doesn't need to, certainly; it is also possible that saving some additional data for these more elaborate features requires more space than without. At least it's quite probable that there need to be fewer intra encoded blocks, so the encoding can be more efficient, in general. Yet, in practice, most users won't need any slower preset than "slower". And "placebo" is certainly a waste of time and energy.

In addition, the target for the CRF mode is the "rate factor", a metric for the loss of quality. It is possible that the features enabled in a faster preset may return more efficient results for a specific video material than the enabled features of a slower preset. There are no guarantees.
Thank you for your help, Everybody! - it seems that my (quite logical) assumption that higher-level preset will automatically result in better QP or bitrate is questionable at best - I'll do more tests on a different video material to confirm.

Cheers!
eclipse98 is offline   Reply With Quote
Old 12th April 2021, 15:19   #8099  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
New upload: x265 (Yuuki-Asuna mod) 3.5+2-g2b25c9ba0+45 (Yuuki branch)

MSYS2/MinGW (Win32, Win32XP, Win64)

Code:
x265 [info]: HEVC encoder version 3.5+2-g2b25c9ba0+45
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] Yuuki 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.78.100)
x265 [info]: (libavcodec  58.136.101)
x265 [info]: (libavutil   56.72.100)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 13th April 2021 at 07:07.
LigH is offline   Reply With Quote
Old 13th April 2021, 04:50   #8100  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
Quote:
Originally Posted by LigH View Post
Fun with Yuuki-Asuna again:

Code:
-- x265 Release Version 2.3M+850-g2b25c9ba0+47
I always forget to push new tag (3.5) from upstream to my repo, so it slips all the way to 2.3. Simply let me know next time if I forget again.

Also I've rewritten ruby code with native cmake code. It should now work without ruby package.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain 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 00:40.


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