Recherche avancée

Sur d’autres sites (2932)

• Linking VLC build to ffmpeg build libraries

  14 mars 2017, par gatorface

  I’m receiving the following error message when attempting to build VLC :

  checking for mad_bit_init in -lmad... yes
checking for MPG123... yes
checking for libavutil variant... libav
checking for GST_APP... yes
checking for GST_VIDEO... yes
checking for AVCODEC... no
configure: error: Requested 'libavcodec >= 57.16.0' but version of libavcodec is 56.1.0. Pass --disable-avcodec to ignore this error.

  I am running the command (first step of Configuration from link below, I did the contrib method and built everything else as well) :

  ./configure

  So let’s get the obvious out of the way : I’m missing the most recent version of libavcodec (v57). Using --disable-avcodec is not a viable solution. Doing a quick apt-file search libavcodec I’m seeing that for debian/jessie the latest version published is libavcodec56, not 57. I did also notice that libavcodec57 was available for installation with ffmpeg here https://ffmpeg.org/download.html

  I actually needed to also build ffmpeg from source. So I did that, worked my way through the dependencies without too much trouble using the guide linked to below.

  So here is my issue : After building and doing a make install of ffmpeg, I still get that error above, despite having the latest libavcodec freshly compiled.

  So my question is : since I used that guide, I am still getting the error when building vlc. I see that the lib exists her : /root/ffmpeg_build/lib/libavcodec.a, and I figured make install would put it where it needs to be. Is there some other compile flag I can set while compiling vlc to point it to that lib directory to look for libavcodec ?

  ffmpeg build : https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
  vlc build : https://wiki.videolan.org/UnixCompile/

  ---

  UPDATE : tried this, still getting the error message : PKG_CONFIG_PATH="/root/ffmpeg_build/lib:$PKG_CONFIG_PATH" LD_LIBRARY_PATH="/root/ffmpeg_build/lib:$LD_LIBRARY_PATH" ./configure

  ---

  UPDATE2 : tried this, still getting the error message : ./configure --libdir="/root/ffmpeg_build/lib:$LIBDIR"

  ---

  UPDATE3 : I tried merging my ffmpeg libs into my vlc libs and may have made things worse. My ffmpeg libs lived here : /root/ffmpeg_build/lib
  My vlc build (contrib builds as well) lived here : /opt/vlc/

  So I merged them with my existing vlc contrib lib :

  cp /root/ffmpeg_build/lib/* /opt/vlc/contrib/x86_64-linux-gnu/lib/
cp /root/ffmpeg_build/lib/pkgconfig/* /opt/vlc/contrib/x86_64-linux-gnu/lib/pkgconfig/

  Then ran configure :
  ./configure --with-contrib=contrib/x86_64-linux-gnu

  Which finally worked, but now I get this error when I try to make :

  Now I get the error :
  /usr/bin/ld: /opt/vlc/contrib/x86_64-linux-gnu/lib/libavformat.a(allformats.o): relocation R_X86_64_32 against `ff_a64_muxer' can not be used when making a shared object; recompile with -fPIC

• Why is one ffmpeg webm dash stream much larger than the others ?

  5 janvier 2017, par ranvel

  Over the summer, I worked on putting together a script which took a x264 video/mp3 stream and broke it up into the different streams so that it would work via MSE-DASH. (Based heavily on the instructions on the webmproject.org website) Those same scripts have ceased to work, turning a 6GB video into several 25 Gb videos. I kept up with updates of ffmpeg and so I don’t know when it stopped working, but I am guessing it was due to the way that their DASH Webm implementation was updated.

  I found new method which works better, but still has a major problem with one stream. I was hoping someone could explain how this encoding works so that I could understand the underlying cause.

  #!/bin/bash
  
  COMMON_OPTS="-map 0:0 -an -threads 11 -cpu-used 4 -cmp chroma"
  
  WEBM_OPTS="-f webm -c:v vp9 -keyint_min 50 -g 50 -dash 1"
  
  
  
  ffmpeg -i $1 -vn -acodec libvorbis -ab 128k audio.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 500k -vf scale=1280:720 -y vid-500k.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 700k -vf scale=1280:720 -y vid-700k.webm & 
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 1000k -vf scale=1280:720 -y vid-1000k.webm &
  
  ffmpeg -i $1 $COMMON_OPTS $WEBM_OPTS -b:v 1500k -vf scale=1280:720 -y vid-1500k.webm  

  The transcode is not yet complete, but you can see where this is headed :

  -rw-r--r--  1 user  staff    87M Jan  4 23:27 audio.webm
  
  -rw-r--r--  1 user  staff    27M Jan  4 23:42 vid-1000k.webm
  
  -rw-r--r--  1 user  staff   285M Jan  4 23:42 vid-1500k.webm
  
  -rw-r--r--  1 user  staff    15M Jan  4 23:42 vid-500k.webm
  
  -rw-r--r--  1 user  staff    20M Jan  4 23:42 vid-700k.webm

  The 1500k variant is disproportionately larger than the other streams.

  The other problem is that when I use a shorter video, lets say eight or nine minutes, the above configuration runs as expected and everything is perfect. I don’t know where the limit for this is since each test costs a lot of processing power and time, but if it’s less than ten minutes, it works and if its longer than an hour, it produces massive files.

• Merge commit ’014852e932dab6e9cf2a53e7a17ce8321f3e922c’

  19 mars 2017, par Clément Bœsch

  Merge commit ’014852e932dab6e9cf2a53e7a17ce8321f3e922c’
  * commit ’014852e932dab6e9cf2a53e7a17ce8321f3e922c’ :
  
    simple_idct : arm : Drop disabled code variant
  Merged-by : Clément Bœsch <u@pkh.me>
  

  • [DH] libavcodec/arm/simple_idct_armv5te.S