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. |
24th August 2019, 11:48 | #7002 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Somebody reported an error, encoding finishes but returns exit code 1 at the end, has that a special meaning? What could be the reason?
CPU : AMD Ryzen 9 3900X 12-Core Processor ---------- Video encoding using x265 3.1+11-de920e0 Wolfberry ---------- "C:\Program Files (x86)\VapourSynth\core\vspipe.exe" K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb.vpy - --y4m | C:\Users\Renor\Desktop\StaxRip\Apps\Encoders\x265\x265.exe --crf 20 --output-depth 12 --aq-mode 1 --frames 132 --y4m --output K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb_out.hevc - The system cannot find the path specified. y4m [info]: 1280x720 fps 25/1 i420p8 frames 0 - 131 of 132 raw [info]: output file: K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb_out.hevc x265 [info]: HEVC encoder version 3.1+11-de920e0a3183 x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 12bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 x265 [info]: Main 12 profile, Level-3.1 (Main tier) x265 [info]: Thread pool created using 24 threads x265 [info]: Slices : 1 x265 [info]: frame threads / pool features : 4 / wpp(12 rows) x265 [info]: Coding QT: max CU size, min CU size : 64 / 8 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 3 x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00 x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2 x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0 x265 [info]: References / ref-limit cu / depth : 3 / off / on x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1 x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60 x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao Output 132 frames in 1.92 seconds (68.61 fps) x265 [info]: frame I: 1, Avg QP:20.28 kb/s: 21838.80 x265 [info]: frame P: 31, Avg QP:20.75 kb/s: 4661.11 x265 [info]: frame B: 100, Avg QP:27.32 kb/s: 311.44 x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0% x265 [info]: consecutive B-frames: 3.1% 9.4% 3.1% 40.6% 43.8% encoded 132 frames in 2.28s (57.92 fps), 1496.04 kb/s, Avg QP:25.73 ------- Error Video encoding using x265 3.1+11-de920e0 Wolfberry ------- Video encoding using x265 3.1+11-de920e0 Wolfberry failed with exit code: 1 (0x1) The exit code might be a system error code: STATUS_WAIT_1 The exit code might be a system error code: Incorrect function.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
24th August 2019, 20:08 | #7003 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
31st August 2019, 00:42 | #7004 | Link |
Registered User
Join Date: May 2018
Posts: 49
|
Regarding RDOQ, am I the only one who really doesn't like the look of it? Though it's effective at maintaining grain motion, it seems to make it awfully boxy. I realise that this is subjective, but I find the results from disabling RDOQ entirely (--rdoq-level 0 --psy-rdoq 0) and increasing Psy-rd (to anywhere between 2.5 to 3.5) to be consistently more pleasing, assuming the same bitrate. Especially in grainy animation. The only explanation I can come up with for this comes from the documentation: that underlying flat colours reveal the shortcomings of RDOQ "biasing towards energy in general" as opposed to "energy in the source". On live action it seems okay, but I've found a number of instances in animation where anything other than tiny amounts can be quite ugly and make a right mess of fine grain or dither, regardless of the bitrate.
My apologies if that sounds overly negative; I realise that there are folks here who know a lot more than I do. Perhaps I'm missing something? Outside of a few difficulties with deep reds, this is really the only head-scratcher I've run into with x265. The only thing I long for is a way to control the strength of SAO. I like it, but sometimes I think half as much or even less would do. |
4th September 2019, 16:39 | #7005 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v3.1+14-f08461fdae33 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default |
5th September 2019, 06:49 | #7006 | Link |
SuperVirus
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
|
Regarding v3.1+14-f08461fdae33...
sadly the compiler warnings are back — for example, Code:
D:/KOMPILES/MCW/x265/source/encoder/analysis.cpp:2498:54: warning: this statement may fall through [-Wimplicit-fallthrough=] 2498 | case 3: mvpSelect[2] = mode.amvpCand[list][ref][!(mode.cu.m_mvpIdx[list][pu.puAbsPartIdx])]; | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ D:/KOMPILES/MCW/x265/source/encoder/analysis.cpp:2499:33: note: here 2499 | case 2: mvpSelect[1] = mvp; | ^~~~ [ 77%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.obj D:/KOMPILES/MCW/x265/source/encoder/search.cpp: In member function 'void x265_12bit::Search::predInterSearch(x265_12bit::Mode&, const x265_12bit::CUGeom&, bool, uint32_t*)': D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2276:42: warning: this statement may fall through [-Wimplicit-fallthrough=] 2276 | mvpIdxSel[2] = !mvpIdx; | ~~~~~~~~~~~~~^~~~~~~~~ D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2277:21: note: here 2277 | case 2: mvpSel[1] = interMode.amvpCand[list][ref][mvpIdx]; | ^~~~ D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2278:42: warning: this statement may fall through [-Wimplicit-fallthrough=] 2278 | mvpIdxSel[1] = mvpIdx; | ~~~~~~~~~~~~~^~~~~~~~ D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2279:21: note: here 2279 | case 1: mvpSel[0] = interDataCTU->mv[list][cuIdx + puIdx].word; | ^~~~ Code:
-- cmake version 3.15.2 CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy): The OLD behavior for policy CMP0025 will be removed from a future version of CMake. The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that a policy should be set to OLD only under specific short-term circumstances. Projects should be ported to the NEW behavior and not rely on setting a policy to OLD. CMake Deprecation Warning at CMakeLists.txt:16 (cmake_policy): The OLD behavior for policy CMP0054 will be removed from a future version of CMake. The cmake-policies(7) manual explains that the OLD behaviors of all policies are deprecated and that a policy should be set to OLD only under specific short-term circumstances. Projects should be ported to the NEW behavior and not rely on setting a policy to OLD. Last edited by filler56789; 5th September 2019 at 06:55. Reason: emphasis |
5th September 2019, 07:06 | #7007 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
5th September 2019, 07:28 | #7008 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
@filler56789 - I do not remember anymore when I mentioned "deprecated CMake policies" to the developer mailing list ... could be more than a year ago already. They are still supported, and I can only hope that abandoning them won't break it for long.
|
10th September 2019, 17:00 | #7009 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
I'll try to mux and upload before I head to IBC. |
|
11th September 2019, 07:44 | #7010 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Just a side note:
Recently I found archives of images stored in BPG format (Better Portable Graphics), a variant of HEIF. Trying to view them, I found that some famous Windows image viewers don't support it well, partially due to license doubts (IrfanView). For XnView I found a plugin which substitutes the partial support (bpgdec) by basic support via an encoder using x265, but it is not easily configurable (only via configuration file, globally). Web browsers can display BPG images via a JavaScript decoder for the HTML5 Canvas, written by the format author Fabrice Bellard. The decoders I found so far are not very optimized, especially not multithreaded. Decoding a 150 MPx image takes several seconds. (You will probably guess well if you ask yourself who owns one of such 50K$ cameras...) |
11th September 2019, 19:01 | #7011 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
Chrome and Firefox have been hard-coded to explicitly not pass through HEVC streams to the system decoders, although they do so for H.264. It'd be a trivial tweak to Chromium to re-enable that. |
|
12th September 2019, 13:12 | #7012 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
I also mean the decoding speed in separate image viewers. Especially sad for IrfanView, which used to be among the fastest for several formats, but is afraid of license trouble when implementing a HEIF decoder. (Or is it the encoder part, to implement the support only wholesome or not at all?)
Has libavcodec a multi-threaded HEVC decoder? I believe so... |
13th September 2019, 05:26 | #7013 | Link | |
Registered User
Join Date: Dec 2018
Posts: 21
|
Quote:
Did you change the order of the printed parameters in x265_param2string()? The "Encoding settings"-field in the produced metadata header from your binary is in a completely different order than what is the default on x265. It's really weird to see that when you're used to certain parameters being in a particular place. Can't say I'm a fan of this "customization". |
|
13th September 2019, 11:10 | #7014 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,815
|
Quote:
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
|
13th September 2019, 11:31 | #7015 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v3.1+19-c4b098f973e6 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default |
14th September 2019, 11:40 | #7016 | Link |
Registered User
Join Date: Jan 2019
Location: Russia
Posts: 105
|
What about new option --selective-sao? Anybody knows should i disable it, like --no-sao earlier?
https://bitbucket.org/multicoreware/...f47?at=default Last edited by redbtn; 14th September 2019 at 11:46. |
14th September 2019, 20:31 | #7017 | Link | |
Registered User
Join Date: Jan 2019
Location: Canada
Posts: 574
|
Quote:
You can disable it all with --selective-sao 0 --no-sao |
|
15th September 2019, 09:29 | #7018 | Link | |
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,277
|
The confusing part is that
a. just using '--no-sao' doesn't disable SAO, you get Quote:
b. With 'selective-sao' is described as 'Disable SAO for all slices', what is SAO used on if you use '--selective-sao 0 --sao' ? looking at the code: Code:
if (!!m_param->selectiveSAO) { Slice* slice = frameEnc->m_encData->m_slice; slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 1; switch (m_param->selectiveSAO) { case 3: if (!IS_REFERENCED(frameEnc)) slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0; break; case 2: if (!!m_param->bframes && slice->m_sliceType == B_SLICE) slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0; break; case 1: if (slice->m_sliceType != I_SLICE) slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0; break; } } else { Slice* slice = frameEnc->m_encData->m_slice; slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0; }
Cu Selur Last edited by Selur; 15th September 2019 at 10:05. |
|
15th September 2019, 14:18 | #7019 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
--no-sao should definitely mean switching SAO off completely. It's ridiculous to add some other parameter affecting the choice.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
|