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. |
14th January 2021, 20:32 | #7942 | Link |
Registered User
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 377
|
Undefined reference usually means that symbol is not reachable. For example, there is no library with such names supplied to the linker. Check generated build files if all needed ffmpeg libs are actually provided for linking.
|
15th January 2021, 00:18 | #7944 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
If a C/C++ application depends on library 'XYZ', the you will need to do two things:
Of course you will need to build library 'XYZ' before you build your "main" application, because otherwise the required library file libXYZ.a (the "build file") has not been created yet Quote:
(If you try to link against a library, but the linker couldn't find the requested library file, it would be a different error message) Another "fun" thing needs to be considered: Libraries can be compiled as either a "static" library (.a) or a "shared" library (.dll). Specifically on Windows, the actual symbol names differ between the "static" and "shared" libraries! Usually the header files support both variants, via #ifdef's, but default often is the "shared" variant. So, a special #define needs to be set, at compile-time, if you intend to link against the "static" library. Could also be the other way around tough
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 15th January 2021 at 01:06. |
|
15th January 2021, 01:56 | #7945 | Link |
Registered User
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 377
|
If you're using mingw (as I am), they are in the generated build folder. For example, CMakeFiles\cli.dir\linklibs.rsp. If you generated msvc project, it's somewhere in the linker options.
|
15th January 2021, 08:55 | #7946 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
The only *.rsp files I see are objects1.rsp in 8bit/CMakeFiles/x265-shared.dir (I'm trying to make a multi-lib static build). It contains only obj files created by the basic x265 compilation.
With -DENABLE_AVISYNTH=ON in the cmake configuration, the x265.exe contains avs_ symbols; AviSynth+ headers are present in local includes. With -DENABLE_VPYSYNTH=ON in the cmake configuration, the x265.exe contains vsscript_ symbols; libvapoursynth.a + vapoursynth[-script].pc are present in local libs[/pkgconfig]. With -DENABLE_LSMASH=ON in the cmake configuration, the x265.exe contains LSMASH_ symbols and even a version number (printed in the version console output); liblsmash{a|pc} are present in local libs[/pkgconfig]. With -DENABLE_ZIMG=ON in the cmake configuration, the x265.exe contains zimg5graph12_ symbols; libzimg.a + zimg.pc are present in local libs[/pkgconfig]. All that works without any other *.rsp files. {libavcodec|libavdevice|libavfilter|libavformat|libavif|libavutil}.{a|pc} are present in local libs[/pkgconfig]. Apparently, with -DENABLE_LAVF=ON in the cmake configuration, cmake detects them (or would error out otherwise), so I assume ld can find them like all the other libraries (especially like lsmash and zlib). Headers and libraries should match because MABS compiled a whole ffmpeg the other day, before I tried to build x265_Asuna afterwards. Therefore I agree with: Quote:
PS: x265cli.cpp.obj and objects.a contain libav* version string format templates; lavf.cpp.obj and objects.a contain avformat_close_input. Does the command line need more extra parameters that ff libs can be linked correctly? Last edited by LigH; 15th January 2021 at 09:15. |
|
15th January 2021, 14:58 | #7947 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,420
|
|
15th January 2021, 15:38 | #7948 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
@qyot27:
ENABLE_STATIC_LAVF should be enabled by default (if LAVF and CLI are enabled), if I read that first location correctly; I already found this option, still tried to enable it explicitly in the cmake command line parameters (-DENABLE_STATIC_LAVF=ON), but it did not help as such... VapourSynth, LSMASH and ZIMG packages are found without CMAKE_PREFIX_PATH, and I believe libav libraries (via the "FF" package) are found too; just linking them fails for a different reason. As if they are found but not used, maybe... |
16th January 2021, 14:48 | #7949 | Link | |
Registered User
Join Date: Jan 2017
Posts: 48
|
What CLI option(s) should I be tweaking to help stop chroma bleed? It seems that no matter how low I go with CRF, my reds will still bleed out into neighboring areas
My options are roughly a mix of veryslow and placebo, with some other options thrown in. Here's one from a recent 1080p/HDR test: Quote:
I know my settings are a bit absurd, I'm getting around 1.2FPS on a 3900X with around 60% load, but my goal is transparency mostly, with a tiny hint of keeping speeds above 1FPS Side question: Is there anyway to increase load usage with command line x265 without affecting PQ? Ie without using something like RipBot's distributed encoding |
|
16th January 2021, 15:18 | #7950 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
Chroma bleeding is actually really weird, it shouldn't really happen and I think I know why it's happening to you!
Your input is an AVS Script from what I see, which handles 4:2:0 Type 1 but not 4:2:0 Type2! So, the chroma location is wrong, hence the "bleeding". Can you try with: Code:
ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m - --dither |
22nd January 2021, 10:48 | #7951 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
Success! With the great support of Christopher Degawa, main supporter of the media-autobuild suite, I was able to tweak my workflow until I could build an x265 binary with Yuuki-Asuna mod (Asuna branch = based on v3.4-stable). It required some pkgconfig tuning and I found a way to use the "video decoders only" light ffmpeg build as already used by m-ab-s in its x264 binary (option 6); so it should contain support for AVS input, VPY input, LAVF input, MP4 output (L-SMASH), MKV output (Haali, obsolete), and ZIMG scaling.
x265 3.4-Asuna+54 Code:
x265 [info]: HEVC encoder version 3.4+-+54 x265 [info]: build info [Windows][GCC 10.2.0][64 bit] Asuna 8bit+10bit+12bit x265 [info]: (lsmash 2.16.1) x265 [info]: (libavformat 58.65.101) x265 [info]: (libavcodec 58.117.101) x265 [info]: (libavutil 56.63.101) |
22nd January 2021, 20:03 | #7952 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
At 4K resolutions, getting it wrong is pretty hard to see, but the lower the frame size, the more screen area an error will take up. |
|
23rd January 2021, 13:10 | #7953 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
Update with correct version numbering
x265 3.4+13-g729a838d3+41 (Asuna) Code:
x265 [info]: HEVC encoder version 3.4+13-g729a838d3+41 x265 [info]: build info [Windows][GCC 10.2.0][64 bit] Asuna 8bit+10bit+12bit x265 [info]: (lsmash 2.16.1) x265 [info]: (libavformat 58.65.101) x265 [info]: (libavcodec 58.117.101) x265 [info]: (libavutil 56.63.101) |
23rd January 2021, 16:43 | #7954 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v3.4+37-dd1101b6d (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)
Code:
https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5 |
24th January 2021, 14:06 | #7955 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,904
|
Quote:
|
|
25th January 2021, 10:43 | #7956 | Link | |
Registered User
Join Date: Aug 2018
Posts: 21
|
Quote:
|
|
25th January 2021, 19:30 | #7959 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
SAO can definitely be helpful at moderate-low bitrates. But the x265 implementation has fixed parameters for SAO. Adjusting them some based on bitrate or QP or content analysis could make it a more reliable net benefit even at high bitrates and high detail. |
|
26th January 2021, 21:43 | #7960 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|