v2.8.2 r230907 x64 error - export x265_api_get_209 not found in libx265.dll

[VictorVG]

when running nightie v2.8.2 r240907, a message is displayed twice that the entry point x265_api_get_209 was not found in libx265.dll. A search for the source showed that this entry point is used by .\plugins\videoEncoders\libADM_ve_x265_other.dll and plugins\videoEncoders\qt5\libADM_ve_x265_QT5.dll , but there is no such export in libx265.dll and the build from 05/31/2024, there is x265_api_get_199. At the same time, hardware encoding on Win7 SP1 x64 with the NVIDIA driver r474.44 works, which is evident from the 78% GPU load during the count of 4% CPU load in the System Information window of Process Hacker 3.0. and the HWiNFO64 sensor logs confirm this - CPU load <= 10.2%, GPU 42.3%, GPU codecs 96.8%.

It seems to me that the entry point is mixed up in these libraries and it should be x265_api_get_199, not x265_api_get_209.

I did not find an answer to this question in the source code, but perhaps I did not understand where and what to look for and searched for the x265_api_get_209 template.

[eumagga0x2a]

MXE has been regenerated. Presumably due to a packaging error an old (v3.5) libx265.dll got packaged with the new Avidemux cross-compiled build where the x265 plugin had been compiled against x265 v3.6.

[VictorVG]

Understood. So far, I "chewed" - corrected the name of the call - he believes that the video was not damaged. True X265 I checked for not the largest video, but the Huawei Mediapad M5 Lite 10 tablet lost without problems. And x264 - there just "gift" came - Winx YouTube Downloader V6.8 (Latest) when downloading with RUTUBE if you come across a video with a constant framework in 70% of cases will save it with variables and the equipment does not take this, or the downloaded utility had the size of a gigabyte , and the saved file is hundreds of megabright and damaged - choose less resolution and download again. So you have to catch in ./<target>/<random*>/temp.mp4, make a hardlink on it with the name ../<<name>.TS because Hosting gives MPEG-TS, and FFMPEG 4.2.2 built in WinX converts him "correctly". And if the same .ts counting in ADM there are no errors. The only thing you have to is to use the Resample filter indicating the frame rate - otherwise we will get a variable and indicate the parameters of the recoding sound - the reasons are the same. Well, the source is such, adapted.

[VictorVG]

MXE has been regenerated. Presumably due to a packaging error an old (v3.5) libx265.dll got packaged with the new Avidemux cross-compiled build where the x265 plugin had been compiled against x265 v3.6.

Big thanks! I test new build v2.8.2 r240907 in to download Digiraty WinX MPEG 4 part 10 file "test.mp4"- real MPEG-TS use Nvidia H264 and Nvidia HEVC encoder on system:

Xeon E5 2697v2 / Intel MD82C602J / 64 (4 x 16) REG ECC DDR3-1866 Quad Channel / NVIDIA GTX 16600 Ti, OS Win7 SP1 x64 and NVIDIA driver R474.44 x64

both test success, Huawei MediaPad M5 Lite 10 (SoC Kirin 695) play test video success, w/o error's or lost frames.

H.264 test (Process Hacker SI, CPU load, GPU load):



H.265 test (Process Hacker SI, CPU load, GPU load):



bug fixed, OK!.

[eumagga0x2a]

Packaging fixed in r240908. Additionally, a few unneeded DLLs identified and excluded from packaging, thus smaller package size.

Setting the topic non-sticky.