Update FFmpeg to 2.5.3

[durack1]

It seems we're a long way behind the current FFmpeg latest (0.11.1 vs 2.5.3) - https://www.ffmpeg.org/download.html

It also seems to be available through github: https://github.com/FFmpeg/FFmpeg

@doutriaux1 should this package be updated?

[doutriaux1]

@aashish24 @dlonie does VTK comes with its' own built-in ffmpeg? Does it build it if not found? If so we might as well turn off the ffmpeg build all together and use VTK's

[alliepiper]

@doutriaux1 We have FFMPEG based exporters, but they rely on an external FFMPEG installation -- we do not package our own with VTK.

[durack1]

@dlonie I also wondering if the tiff, jpeg and png libraries which are currently built within UV-CDAT are also bundled with VTK? It would be good to remove duplication if there is some..

[alliepiper]

For reference, here are the third party packages that are bundled with VTK (see VTK/ThirdParty):

• alglib
• AutobahnPython
• exodusII
• expat
• freerange
• freetype
• ftgl
• gl2ps
• glew
• hdf5
• jpeg
• jsoncpp
• libproj4
• libxml2
• mpi4py
• netcdf
• oggtheora
• png
• SixPython
• sqlite
• TclTk
• tiff
• Twisted
• utf8
• verdict
• VPIC
• xdmf2
• xdmf3
• zlib
• ZopeInterface

Looks like there is indeed some overlap. The only issue I can think of is that VTK renames the library files to prevent conflicts with system libraries (e.g. libvtkpng.so instead of libpng.so). These are designed to be replaced by system libraries, but not vice-versa -- I'm not sure that we'd be able to expose these easily to other components of UVCDAT.

[durack1]

@dlonie so from a quick scour: hdf5, jpeg, libxml2, mpi4py, netcdf, png, tiff and zlib are likely duplicate candidates.. If you folks are already doing the job of keeping these libraries up-to-date in VTK then I think it'd be good to consider removing the duplication.. If indeed it's easy to expose these..

[alliepiper]

Well, I'm not sure we have the ability to expose these -- people usually want to link VTK to their system libraries, not the other way around. Also, we usually don't update these unless something breaks or there is a specific reason to, so I wouldn't count on them being newer than what's in the superbuild ;)

[durack1]

@dlonie so how about the reverse.. If we promise to keep the libraries up-to-date in UV-CDAT, could VTK use these libraries rather than bundling it's own?

It really would be nice to reduce the build footprint down from the ~8Gb or so it's at currently..

[alliepiper]

That would be much easier. All we need to do is set VTK_USE_SYSTEM_${pkg} in the VTK configure step and it will use the other ones. We already do this for zlib, libxml, hdf5, netcdf, and freetype (see CMake/cdat_modules/vtk_external.cmake in the UVCDAT src tree).

If we decide to do this, let's open a new issue for it.

[doutriaux1]

@durack1 there's no duplicate build. The VTK build goes to great length to force using UV-CDAT built libraries.

[durack1]

@doutriaux1 so the tiff, jpeg and png libraries are not built for both?

[durack1]

@doutriaux1 a 2.3 candidate..