Recherche avancée

Sur d’autres sites (6734)

• Building and packaging a portable ffmpeg Linux program ('GLIBC_2.27' not found) [duplicate]

  7 mai 2018, par Blue4Whale

  This question already has an answer here :

  • Deploying Yesod to Heroku, can’t build statically
    
    3 answers
    

  I am trying to build a portable version of ffmpeg to run on major Linux distributions, with the final user only having to extract the distributed targz package to the appropriate directory.

  My previous builds on Ubuntu 16.04 worked fine. I upgraded to Ubuntu 18.04 and new builds, when run on Fedora 27 with LD_LIBRARY_PATH=. ./ffmpeg, show errors :

  ./ffmpeg: /lib64/libm.so.6: version `GLIBC_2.27' not found (required by ./libavfilter.so.7)
  
  ./ffmpeg: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by ./libavformat.so.58)

  Which i interpret as the libavxxx libraries want to dynamically link against system libraries libc and libm that would have been compiled with GLIBC_2.27, but those libs have been compiled with an older GLIBC version.

  Note that the fact the errors show from libavxxx.so is not the point, as if i compile ffmpeg as a fat binary (libavxxx linked statically), i get the same error from ffmpeg.

  The only workaround i have found so far is to copy the build system libc.so.6 and libm.so.6 libraries to the directory containing the binaries and make them part of the ffmpeg package.

  Is there a better way to handle this issue ?

• avcodec/dnxhddata : move avpriv_dnxhd_parse_header_prefix to a header

  25 juillet 2016, par James Almer

  avcodec/dnxhddata : move avpriv_dnxhd_parse_header_prefix to a header
  It’s a small and simple function that can be inlined.
  This removes one private symbol and should reduce object dependencies with the next
  
  major bump
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavcodec/dnxhddata.c
  • [DH] libavcodec/dnxhddata.h
  • [DH] libavcodec/dnxhddec.c
  • [DH] libavformat/dnxhddec.c
  • [DH] libavformat/movenc.c

• x264 encoding taking longer when encoding static frames (than

  14 septembre 2015, par Danilo

  ​Hi,
  I’m using x264 for live video streaming and I’ve noticed that the thread
  responsible for encoding uses ​​more cpu (sometimes 50% more with 1920x1080) when the video stream is frozen (i.e. : camera is sending the same frame over an over again) or when I make it encode the same image over and over again.

  This seems somewhat counter intuitive to me, as I would expect x264 to use
  more processing power when encoding complex scenes other then static ones.

  My encoder settings are the following :

  1280x720 fps=25/1 timebase=0/0 bitdepth=8 cabac=0 ref=1 deblock=1:0:0 analyse=0x3:0x113
  
  me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
  
  8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=0
  
  sliced_threads=0 slice_max_size=1190 nr=60 decimate=1 interlaced=0 bluray_compat=0
  
  constrained_intra=0 bframes=0 weightp=0  keyint=1200 keyint_min=120 scenecut=40
  
  intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=24.0 qcomp=0.60 qpmin=0 qpmax=69
  
  qpstep=4 vbv_maxrate=1024 vbv_bufsize=350 crf_max=35.0 nal_hrd=none

  I created a github gist based on the example.c encoder bundled in x264’s
  source code and tested encoding times with it. (You can find it here :
  https://gist.github.com/danilogr/ab4976ff4e0831ab274b)

  Average encoding time for the static scene is 38% bigger than for a scene
  with movements. (You can find my test case and also the output from my test
  encoder on the link above).

  ​​
  ​I’ve also noticed that by setting ​​scenecut=0, subme=0, trellis=0 and me=dia I can get rid of this problem​, but with noticeable quality​ decrease.

  ​
  ​Could anyone, please, shed some light on the reasons for this odd behavior ?
  ​Also, what can be done in order to avoid this situation without a major decrease in quality ?​