New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update FFmpeg to 2.5.3 #1029

Closed
durack1 opened this Issue Feb 11, 2015 · 11 comments

Comments

Projects
None yet
4 participants
@durack1
Member

durack1 commented Feb 11, 2015

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

This comment has been minimized.

Member

doutriaux1 commented Feb 11, 2015

@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

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Feb 11, 2015

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

@durack1

This comment has been minimized.

Member

durack1 commented Feb 11, 2015

@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..

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Feb 11, 2015

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

This comment has been minimized.

Member

durack1 commented Feb 11, 2015

@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..

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Feb 11, 2015

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

This comment has been minimized.

Member

durack1 commented Feb 11, 2015

@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..

@allisonvacanti

This comment has been minimized.

Contributor

allisonvacanti commented Feb 11, 2015

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

This comment has been minimized.

Member

doutriaux1 commented Feb 11, 2015

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

@durack1

This comment has been minimized.

Member

durack1 commented Feb 11, 2015

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

@durack1

This comment has been minimized.

Member

durack1 commented Feb 20, 2015

@doutriaux1 a 2.3 candidate..

@doutriaux1 doutriaux1 added the Build label Feb 20, 2015

@doutriaux1 doutriaux1 added this to the 2.3 milestone Feb 20, 2015

@durack1 durack1 closed this in ff225e6 Jun 12, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment