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 14th January 2021, 19:48   #7941  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
I have no idea about that. Maybe check if the lib files are correctly found by gcc.
The error message looks like it didn't find the lib and thus missed the reference to its functions.
__________________
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
Old 14th January 2021, 20:32   #7942  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
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.
__________________
Me on GitHub
PC Specs: Ryzen 5950X, 64 GB RAM, RTX 2070
DJATOM is offline   Reply With Quote
Old 14th January 2021, 21:59   #7943  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
Which are these "build files"?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 15th January 2021, 00:18   #7944  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by LigH View Post
Which are these "build files"?
If a C/C++ application depends on library 'XYZ', the you will need to do two things:
  • At compile-time, you need to ensure that the required header files (usually .h or .hpp) for library XYZ are present in one of the directories that the compiler scans for header files.
    Additional search directories for header files can be specified by adding the -I option to the CFLAGS.
  • At link-time, you need to ensure that library XYZ is actually linked to your binary. This is done by adding the -l option your LDFLAGS.
    Note that -l automatically adds the "lib..." prefix as well as the file extension. So, in order to link against libXYZ.a, you just need to write -lXYZ.

    Furthermore, you have to make sure that the library file (usually .a) is present in one of the directories that the linker scans for library files.
    Additional search directories for library files can be specified by adding the -L option to the LDLAGS.

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:
Originally Posted by LigH View Post
Undefined reference usually means that symbol is not reachable. For example, there is no library with such names supplied to the linker.
Yes, "undefined reference" could mean that a required library was not linked at all. Could also mean that you are linking a "wrong" version of the library which doesn't match to the header files that were used.

(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.
LoRd_MuldeR is offline   Reply With Quote
Old 15th January 2021, 01:56   #7945  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 377
Quote:
Originally Posted by LigH View Post
Which are these "build files"?
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.
__________________
Me on GitHub
PC Specs: Ryzen 5950X, 64 GB RAM, RTX 2070
DJATOM is offline   Reply With Quote
Old 15th January 2021, 08:55   #7946  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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:
Originally Posted by LoRd_MuldeR View Post
(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)
The only doubt I have left: a "light" version of ffmpeg is also a part of other tools, like x264 and cyanrip; but I would like to trust in MABS not to install these system-wide and use them only in the related projects. But even if, it should only limit the selection of codecs, not make basic APIs (like e.g. avformat_close_input) completely unavailable... I guess.

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?
__________________

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

Last edited by LigH; 15th January 2021 at 09:15.
LigH is online now   Reply With Quote
Old 15th January 2021, 14:58   #7947  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,419
https://github.com/msg7086/x265-Yuuk...Lists.txt#L770
and
https://cmake.org/cmake/help/latest/...EFIX_PATH.html, if necessary
qyot27 is offline   Reply With Quote
Old 15th January 2021, 15:38   #7948  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
@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...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 16th January 2021, 14:48   #7949  |  Link
PoeBear
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:
avs2yuv.exe "Test.avs" - | "x265.exe" -D 10 --crf 14 --profile main10 --level-idc 5.1 --high-tier --preset placebo --input-depth 16 --cu-lossless --pmode --bframes 16 --qg-size 32 --frame-threads 4 --ref 6 --limit-refs 1 --merange 57 --no-amp --tskip --tskip-fast --limit-modes --no-open-gop --hrd --cbqpoffs -0 --crqpoffs -1 --no-cutree --deblock -2:-2 --psy-rd 2.50 --psy-rdoq 1.00 --qcomp .6 --aq-mode 2 --aq-strength 1.0 --ipratio 1.3 --pbratio 1.2 --vbv-bufsize 160000 --vbv-maxrate 160000 --aud --hdr10 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 602,187 --chromaloc 2 --repeat-headers --output "C:\Temp\Test.hevc" --frames 5000 --y4m -
I've tried a few numerous tweaks: amp, no-amp, pmode, no-pmode, pme, no-pme, hme instead of merange, dropping cbqpoffs/crqpoffs a bit further. All which really only affect very minor detail retention, likely due to such low CRF, but I still get color bleeds

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
PoeBear is offline   Reply With Quote
Old 16th January 2021, 15:18   #7950  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
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
followed by the rest of your x265 command line? This should solve the chroma bleeding problem.
FranceBB is offline   Reply With Quote
Old 22nd January 2021, 10:48   #7951  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 22nd January 2021, 20:03   #7952  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by FranceBB View Post
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".
Chromaloc seems like a big misfire to me at this point, since so many encoders and decoders don't actually encode/decode differently based on the parameter. Other than for HDR Blu-Ray, which requires chromaloc 2, I recommend leaving it at the default for broader compatibility.

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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 23rd January 2021, 13:10   #7953  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
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)
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is online now   Reply With Quote
Old 23rd January 2021, 16:43   #7954  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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
Barough is offline   Reply With Quote
Old 24th January 2021, 14:06   #7955  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by benwaggoner View Post
Chromaloc seems like a big misfire to me at this point, since so many encoders and decoders don't actually encode/decode differently based on the parameter. Other than for HDR Blu-Ray, which requires chromaloc 2, I recommend leaving it at the default for broader compatibility.

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.
True, but the thing is that he was using chromaloc 2 in x265 but his input (the AVS Script output) wasn't, so it was just wrong. Either he specifies the normal 4:2:0 or he converts it to type2 and specifies chromaloc 2. That's what I meant
FranceBB is offline   Reply With Quote
Old 25th January 2021, 10:43   #7956  |  Link
outhud
Registered User
 
Join Date: Aug 2018
Posts: 21
Quote:
Originally Posted by LigH View Post
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.
Very nice! Thank you.
outhud is offline   Reply With Quote
Old 25th January 2021, 14:31   #7957  |  Link
K.i.N.G
Registered User
 
Join Date: Aug 2009
Posts: 90
Has anyone done any re-tests recently to see if SAO has improved?
It's been a while since I've tested it and concluded not to use it (removed too much detail)
K.i.N.G is offline   Reply With Quote
Old 25th January 2021, 16:28   #7958  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by K.i.N.G View Post
Has anyone done any re-tests recently to see if SAO has improved?
It's been a while since I've tested it and concluded not to use it (removed too much detail)
there hasn't been any work on SAO for a long time. So doubtful
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 25th January 2021, 19:30   #7959  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by microchip8 View Post
there hasn't been any work on SAO for a long time. So doubtful
There was --limit-sao, which provided a pretty nice performance boost without material quality loss when SAO was limited to only I and P frames.

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.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 26th January 2021, 21:43   #7960  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by LigH View Post
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)
Thanks! Any chance you can include 32-Bit binary as well, as you used to do?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR 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 13:25.


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