Xpra: Ticket #253: upgrade libav for win32

Now that we support the latest libav and include it in the static builds for CentOS / old distros, it would be nice to upgrade the win32 builds to something recent and supported (my win32 build machine is at 2012-07-08 git-299387e). Especially since trunk does not build without the old-libav.patch.


Even better would be to build this ourselves so we can get rid of 90% of the compile flags for libav (as per #103).

Sat, 16 Feb 2013 03:38:49 GMT - Antoine Martin:

See also #168 and #159

Sat, 16 Feb 2013 10:42:19 GMT - ahuillet:

Building following instructions in #168 with latest git ffmpeg (as of this writing) seems to produce DLLs correctly. Attaching produced binaries so that you can test (I haven't set up a windows build env yet).

Sat, 16 Feb 2013 10:48:02 GMT - ahuillet:


Includes .a files which must be usable for a static build, which is what we're trying to achieve. libavcodec is still huge - I'll trim the unneeded decoders once we confirm that the build works.

Sat, 16 Feb 2013 11:21:30 GMT - Antoine Martin:

I was hoping you could try the 2 options above (and now possibly the third one you've posted here in comment:3) to see if the resulting codec shared object does load properly or not.

Producing libav/ffmpeg DLLs is not the immediate problem (though if we could use the minimal build instructions from #103, then we can also save space - which is a bonus).

I would really like to understand why the ones I built would not load, preferably with instructions on how to figure this out in case it occurs again in the future.

Sat, 16 Feb 2013 11:31:13 GMT - ahuillet:

depends.exe is going to help a lot, I believe.

As I explained on IRC I do think it's better to produce static builds.

Mon, 18 Feb 2013 15:26:43 GMT - ahuillet:

According to depends.exe's output, codec.pyd tries to import Python-related symbols from all the libav's libs in addition to python27.dll, and it doesn't actually try to import the libav-related functions at all.

The description of the problem matches that at http://forum.videolan.org/viewtopic.php?f=32&t=98097

I've manually verified that adding /OPT:NOREF on the linker commandline generates a codec.pyd that looks fine in depends.exe.

Mon, 18 Feb 2013 15:31:46 GMT - Antoine Martin:

Excellent! Based on this, here is the suggested patch:

--- src/setup.py	(revision 2734)
+++ src/setup.py	(working copy)
@@ -430,6 +430,7 @@
             add_to_keywords(kw, 'libraries', "swscale", "avcodec", "avutil")
             add_to_keywords(kw, 'extra_link_args', "/LIBPATH:%s" % ffmpeg_lib_dir)
             add_to_keywords(kw, 'extra_link_args', "/LIBPATH:%s" % ffmpeg_bin_dir)
+            add_to_keywords(kw, 'extra_link_args', "/OPT:NOREF")
         elif "vpx" in packages[0]:
             add_to_keywords(kw, 'include_dirs', "win32", vpx_include_dir, ffmpeg_include_dir)
@@ -438,6 +439,7 @@
             add_to_keywords(kw, 'extra_link_args', "/LIBPATH:%s" % vpx_lib_dir)
             add_to_keywords(kw, 'extra_link_args', "/LIBPATH:%s" % ffmpeg_lib_dir)
             add_to_keywords(kw, 'extra_link_args', "/LIBPATH:%s" % ffmpeg_bin_dir)
+            add_to_keywords(kw, 'extra_link_args', "/OPT:NOREF")
         elif "pygobject-2.0" in packages[0]:
             add_to_keywords(kw, 'include_dirs', python_include_PATH,
                             pygtk_include_dir, atk_include_dir, gtk2_include_dir,

Mon, 18 Feb 2013 15:51:20 GMT - ahuillet:

Yes, this is the exact patch I independantly tried, and I confirm that it works.


Mon, 18 Feb 2013 16:27:02 GMT - ahuillet: status changed; resolution set

Tue, 26 Feb 2013 05:28:21 GMT - Antoine Martin:

related: #270 (minimal libav win32 build)

Sat, 23 Jan 2021 04:49:41 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/253