1. MulticoreWare Avatar MulticoreWare
  2. mcw
  3. x265_git
  4. Issues

v2.5 does not work in ffmpeg 2.4.x

Issue #360 resolved
tramboni created an issue

i do build ffmpeg 2.4 from time to time, the program i use it for does not support a higher version of it.

now i wanted to include the new x265 v2.5, i can compile it, but it does not work. the avcodec-56.dll does not have proper export functions. there are only 4 of them,

x265_csvlog_encode x265_csvlog_frame x265_csvlog_open x265_dither_image

there should be a lot more, in x265 v2.4 (which works nicely in ffmpeg 2.4) had 541 functions.

sorry, maybe i'm doing something wrong, i'm more or less a noob. but i never had any similar problems with older versions of x265.

i used mingw for compiling.

thanks.

Comments (23)

  2. Pradeep Ramachandran Account Deactivated

    Are you saying that v2.5 of x265 doesn't work with ffmpeg v2.4, or are that the version off ffmpeg v2.4 with v2.5 of x265 doesn't support the proper functions? our x265.def exports a lot more functions. Is your compile chain ensuring that the def.in that gets generated is correctly imported by your tool chain?

    Also, I would seriously encourage you to move towards newer version of ffmpeg. You're working on a 3+ year old branch of ffmpeg!

  3. Bradley Sepos

    We're having a similar issue updating HandBrake from x265 2.4 to 2.5. Cross-compiling with mingw-w64 5.0.2 (or latest master branch) succeeds without error, but the resulting hb.lib goes from 13.7 MB to a few KB. Looks like this affects cross-compiling for recent Libav as well, and probably FFmpeg (untested).

    Results of git bisect:

    $ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
$ git bisect start
$ git log --oneline -1
d5f610973 Add force-flush param option
$ git bisect bad
$ git checkout 2.4
Note: checking out '2.4'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 2c55a9dec... release: Release notes for version 2.4
$ git bisect good
Bisecting: 56 revisions left to test after this (roughly 6 steps)
[bb176913097337afdf93e441c8358a98f0441de4] x86inc: Correctly warn on use of SSE2 instructions in SSE functions
$ git bisect bad
Bisecting: 27 revisions left to test after this (roughly 5 steps)
[11a1f827d10d1a01f83d23f5e4754c33d763d457] Insert additional fields in csv file
$ git bisect good
Bisecting: 13 revisions left to test after this (roughly 4 steps)
[2238df48980c0b90fa60bebf2b8010675b761f75] avx2: 'integral4h' asm code -> 6.01x faster than 'C' version
$ git bisect good
Bisecting: 6 revisions left to test after this (roughly 3 steps)
[718a42b23bd3a9192b39ff083e05f766f20002d1] x86inc: Make cpuflag() and notcpuflag() return 0 or 1
$ git bisect bad
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[28bd8c75ed9d970c20cb55523c75a3dc55a5b025] Fix slicetype mismatch between analysis save and load modes
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
[6681d3313dd6202a1345e350b8e4f8ab4903f4fb] Add csv feature into libx265
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a553b5a418f244dddb097cceaec506e1dc8227df] add support for hdr-opt even when aq-mode is disabled
$ git bisect good
6681d3313dd6202a1345e350b8e4f8ab4903f4fb is the first bad commit
commit 6681d3313dd6202a1345e350b8e4f8ab4903f4fb
Author: Divya Manivannan <divya@multicorewareinc.com>
Date:   Fri Jun 9 18:21:55 2017 +0530

    Add csv feature into libx265

:040000 040000 0af7c90d53f5614a72a5a7331bbe61fa4fe415f0 6a5d7a6955c65858a01746838f4482f2ee750614 M  doc
:040000 040000 eb8f8139d49dd52d40b3dad244476dc01d0a6345 bdaa5bc820e1f97b022148308ba16847b32347f8 M  source
$

    So it would seem the first offending commit is https://bitbucket.org/multicoreware/x265/commits/bf93bf6183a70b49007169fe82ec94cd94a3c6e7. Perhaps someone can assign the author.

    Any help resolving this is appreciated. Thanks.

  5. Pradeep Ramachandran Account Deactivated

    This commit pulled-in the csv feature into the library, as detailed in the commit message. I have assigned the author to take a look.

  6. Divya Manivannan

    We have tested in linux with ffmpeg latest version and 2.4 and x265 version is 2.5+6-d11482e5fedb. It works fine. We will test with mingw.

  8. Nik McNulty

    Just so we're clear, using MinGW to cross-compile a Win64 project integrating v2.5 x265_API libraries will build with no errors or failures, but actually produce a broken library that includes ONLY those few functions coded in x265-extras.h, omitting the hundreds of other functions from elsewhere in the code.

    Simply reverting to v2.4 stable will work perfectly under the exact same build conditions.

    Also, the bisect provided by Bradley above points to a commit between v2.4 & v2.5 that alters the makes for x265-extras. The fact that these broken projects will build without error implies to me that the makes are doing what they've been told to do.

    So, simple question: is it MinGW's fault, the project's config for MinGW's fault, CMake's fault, or Multicoreware's fault? Or some combo?

  9. Pradeep Ramachandran Account Deactivated

    Yes, the issue is clear. We were having some trouble with building libx265 with MinGW as the local version we had a on a dev machine was crashing, and the mingw server to upgrade to the latest version wasn't responding late last week. That is why there has been no updates here.

    As a quick check, can you try to replace the #ifdef _WIN32 in x265-extras.h with #ifdef X265_API_IMPORTS to check if that fixes the problem? I recall running into a similar problem where MinGW behaves differently from other windows SDKs and therefore had to make a tweak like this in x265.h; the identical change isn't made in x265-extras.h.

  10. Divya Manivannan

    Checked the exported functions in libx265 dll, it displays all api functions along with csv funtions.

    I have tried building x265 and ffmpeg with mingw. Build is fine but got STATUS_ACCESS_VIOLATION (0xC0000005) when running ffmpeg. This error is coming even with x265 2.3 version. Static build of x265 and ffmpeg is running. Can you please help me fixing the issue with mingw?

  11. Nik McNulty

    I can confirm that Pradeep's suggestion of altering the "#ifdef" worked!

    x265-extras.h: Line 36 = Change "#if _WIN32" to "#if X265_API_IMPORTS"

    I'm presuming that, under MinGW, this change actually just asserts the "#define LIBAPI" (line 39) in x265-extras.h.

    BTW, x265.h uses #ifdef in the same circumstance (line 43), whereas x265-extras.h uses just #if. Should the define be 0 value (haven't looked), the two directives will operate differently despite the existence of the define. Whether this induces yet another MinGW quirk as well... who knows?

  12. Bradley Sepos

    This seems to be working for me.

    --- x265_2.5/source/x265-extras.h.orig  2017-07-13 07:20:07.000000000 -0400
+++ x265_2.5/source/x265-extras.h   2017-07-31 13:20:23.000000000 -0400
@@ -33,7 +33,7 @@
 extern "C" {
 #endif

-#if _WIN32
+#ifdef X265_API_IMPORTS
 #define LIBAPI __declspec(dllexport)
 #else
 #define LIBAPI

    @divya_m We've found the mingw-w64 packages provided by some distros are broken in one way or another. You may be interested in the mingw-w64 build script I created; we use it to generate the toolchain necessary for cross-compiling HandBrake: https://github.com/bradleysepos/mingw-w64-build

    Cheers

  13. tramboni reporter

    i',m the topic starter, so i need to reply i suppose.

    the above fix works for me, too, i did a PGO build for both x86 and x64 (using x86_64-w64-mingw32-g++ resp. i686-w64-mingw32-g++) the libx265.a now work fine in ffmpeg.

    still i wonder why it worked up to v2.4 with #if _WIN32

    also, the x86 version of a x265.exe with PROFILE_GENERATE:BOOL=ON build does crash, but it does also for versions <v2.5 and is a different issue.

  14. Pradeep Ramachandran Account Deactivated

    Thanks. Looks like MinGW is defining _WIN32 which is expected, but the __declspec(dllexport) is throwing things off-guard. I would like to verify what happens for VS 32-bit and 64-bit build when we move this #if into a #ifdef. Once we understand this, we will have a fix for v2.5 and update with new release builds. Please stay tuned for an update.

    Also, now that x265-extras.h is moved into the library, I wonder if this header is even required. We could move these api functions to our libapi struct and add these functions into the .def file which IMO is the cleaner fix. This may not cleaned up in this release though, as removing that file will require testing with other integrations as well. We will pull this into v2.6 (which should come in a couple of months)

  15. Divya Manivannan

    Thanks Bradley Sepos . I will try with this mingw-w64.

    Tramboni , In v2.4 x265-extras.h is not part of the library.

  16. Bradley Sepos

    we will have a fix for v2.5 and update with new release builds

    Please do not replace the existing 2.5 release and tarball. The project has done such things in the past, and it causes problems downstream. Suggest 2.5.1 or 2.6 please, thank you.

  17. Pradeep Ramachandran Account Deactivated

    @bradleysepos @tramboni - Is the mingw build above trying to build a 32-bit library, or a 64-bit library? If it is trying to build a 64-bit library, then the error is with mingw as it shouldn't be setting _WIN32. If it is trying to build a 32-bit library, then we can make this change after verifying that the straight up 32-bit build in windows doesn't get affected by this change in x265-extras.h.

    Please confirm so that we can work towards closing this item quickly and cutting a new tag if required.

  19. tramboni reporter

    i did compile both, 32-bit and 64-bit x265 libs using the mingw toolchains

    x86_64-w64-mingw32 i686-w64-mingw32

    both had the same issue when i used them in ffmpeg, also i tried different gcc versions (4.9.3 and 6.3 and 7.1), with same result.

  21. Pradeep Ramachandran Account Deactivated

    @tramboni - can you please let us know if the patch works? The patch is in the default branch now. We're starting work on the next tag and would like to make sure this issue is closed in v2.6.

  22. tramboni reporter

    sorry for the delay.

    it now works flawlessly. tested in latest ffmpeg 2.4, it compiled and i was able to record to x265

    thanks.

  24. Log in to comment
Assignee
Type
bug
Priority
trivial
Status
resolved
Component
–
Version
–
Votes
0
Watchers
5