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. |
4th April 2021, 08:49 | #8081 | Link |
German doom9/Gleitz SuMo
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. |
4th April 2021, 11:38 | #8082 | Link | |
Registered User
Join Date: Jun 2020
Posts: 1
|
Quote:
|
|
4th April 2021, 14:56 | #8083 | Link | |
Registered User
Join Date: Jul 2016
Posts: 171
|
Quote:
Which one should I get for Kaby Lake cpu ? |
|
5th April 2021, 11:17 | #8085 | Link | |
Registered User
Join Date: Jan 2009
Posts: 6
|
Quote:
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 |
|
5th April 2021, 21:20 | #8086 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
|
Quote:
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. |
|
7th April 2021, 15:48 | #8087 | Link |
German doom9/Gleitz SuMo
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 |
9th April 2021, 10:19 | #8088 | Link |
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! |
9th April 2021, 10:41 | #8089 | Link |
German doom9/Gleitz SuMo
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... |
9th April 2021, 14:11 | #8091 | Link | ||
Registered User
Join Date: Apr 2009
Posts: 478
|
Quote:
Quote:
|
||
9th April 2021, 17:55 | #8094 | Link |
German doom9/Gleitz SuMo
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. |
10th April 2021, 01:18 | #8095 | Link |
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! |
10th April 2021, 12:15 | #8096 | Link | |
21 years and counting...
Join Date: Oct 2002
Location: Germany
Posts: 716
|
Quote:
=> Longer encoding time, bigger filesizes and higher quality of the output. Last edited by LeXXuz; 10th April 2021 at 12:18. |
|
10th April 2021, 12:43 | #8097 | Link |
German doom9/Gleitz SuMo
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. Last edited by LigH; 10th April 2021 at 12:49. |
10th April 2021, 20:25 | #8098 | Link | |
1.16 MileHi
Join Date: Feb 2008
Location: Denver, CO
Posts: 26
|
Quote:
Cheers! |
|
12th April 2021, 15:19 | #8099 | Link |
German doom9/Gleitz SuMo
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) Last edited by LigH; 13th April 2021 at 07:07. |
13th April 2021, 04:50 | #8100 | Link | |
結城有紀
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
|
Quote:
Also I've rewritten ruby code with native cmake code. It should now work without ruby package. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|