Recherche avancée

Sur d’autres sites (5019)

• make error in OpenCV installation on ubuntu (ffmpeg CODEC_ID_XXXX was not declared in scope)

  22 avril 2015, par Anurag Priyadarshi

  I am trying to install OpenCV following this tutorial. I am through cmake.(The configuration is given at the end.) However make shows error :make[2]: ***[modules/highgui/CMakeFiles/opencv_highgui.dir/src/cap_ffmpeg.cpp.o] Error 1
  One link pointed out reason as different version of opencv and ffmpeg, but I found a piece of code in cap_ffmpeg_impl.hpp that appears to be handling it.

  #if LIBAVCODEC_BUILD >= CALC_FFMPEG_VERSION(54,25,0)
  
  #  define CV_CODEC_ID AVCodecID
  
  #  define CV_CODEC(name) AV_##name
  
  #else
  
  #  define CV_CODEC_ID CodecID
  
  #  define CV_CODEC(name) name
  
  #endif

  Not sure if it is ok for this to be commented.

  Also, I could try installing ffmpeg seperately, but I am not sure how dependencies are handled in this installation around libav.

  Would be thankful for any help in solving this problem, as well as tips/links for OpenCV installation in general.

  make configuration :

  -- General configuration for OpenCV 2.4.11 ====================================
  
  Version control:               unknown
  
  -- 
  
  --   Platform:
  
  --     Host:                        Linux 3.16.0-32-generic i686
  
  --     CMake:                       2.8.12.2
  
  --     CMake generator:             Unix Makefiles
  
  --     CMake build tool:            /usr/bin/make
  
  --     Configuration:               RELEASE
  
  -- 
  
  --   C/C++:
  
  --     Built as dynamic libs?:      YES
  
  --     C++ Compiler:                /usr/bin/c++  (ver 4.9.1)
  
  --     C++ flags (Release):         -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -fdiagnostics-show-option -pthread -march=i686 -fomit-frame-pointer -msse -msse2 -msse3 -mfpmath=sse -ffunction-sections -O2 -DNDEBUG  -DNDEBUG
  
  --     C++ flags (Debug):           -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing -Wno-delete-non-virtual-dtor -fdiagnostics-show-option -pthread -march=i686 -fomit-frame-pointer -msse -msse2 -msse3 -mfpmath=sse -ffunction-sections -g  -O0 -DDEBUG -D_DEBUG
  
  --     C Compiler:                  /usr/bin/cc
  
  --     C flags (Release):           -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wno-narrowing -fdiagnostics-show-option -pthread -march=i686 -fomit-frame-pointer -msse -msse2 -msse3 -mfpmath=sse -ffunction-sections -O2 -DNDEBUG  -DNDEBUG
  
  --     C flags (Debug):             -fsigned-char -W -Wall -Werror=return-type -Werror=address -Werror=sequence-point -Wformat -Werror=format-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wno-narrowing -fdiagnostics-show-option -pthread -march=i686 -fomit-frame-pointer -msse -msse2 -msse3 -mfpmath=sse -ffunction-sections -g  -O0 -DDEBUG -D_DEBUG
  
  --     Linker flags (Release):      
  
  --     Linker flags (Debug):        
  
  --     Precompiled headers:         YES
  
  -- 
  
  --   OpenCV modules:
  
  --     To be built:                 core flann imgproc highgui features2d calib3d ml video legacy objdetect photo gpu ocl nonfree contrib java python stitching superres ts videostab
  
  --     Disabled:                    world
  
  --     Disabled by dependency:      -
  
  --     Unavailable:                 androidcamera dynamicuda viz
  
  -- 
  
  --   GUI: 
  
  --     QT 5.x:                      YES (ver 5.3.0)
  
  --     QT OpenGL support:           YES (Qt5::OpenGL 5.3.0)
  
  --     OpenGL support:              YES (/usr/lib/i386-linux-gnu/libGLU.so /usr/lib/i386-linux-gnu/libGL.so /usr/lib/i386-linux-gnu/libSM.so /usr/lib/i386-linux-gnu/libICE.so /usr/lib/i386-linux-gnu/libX11.so /usr/lib/i386-linux-gnu/libXext.so)
  
  --     VTK support:                 NO
  
  -- 
  
  --   Media I/O: 
  
  --     ZLib:                        /usr/lib/i386-linux-gnu/libz.so (ver 1.2.8)
  
  --     JPEG:                        /usr/lib/i386-linux-gnu/libjpeg.so (ver )
  
  --     PNG:                         /usr/lib/i386-linux-gnu/libpng.so (ver 1.2.51)
  
  --     TIFF:                        /usr/lib/i386-linux-gnu/libtiff.so (ver 42 - 4.0.3)
  
  --     JPEG 2000:                   /usr/lib/i386-linux-gnu/libjasper.so (ver 1.900.1)
  
  --     OpenEXR:                     /usr/lib/i386-linux-gnu/libImath.so /usr/lib/i386-linux-gnu/libIlmImf.so /usr/lib/i386-linux-gnu/libIex.so /usr/lib/i386-linux-gnu/libHalf.so /usr/lib/i386-linux-gnu/libIlmThread.so (ver 1.6.1)
  
  -- 
  
  --   Video I/O:
  
  --     DC1394 1.x:                  NO
  
  --     DC1394 2.x:                  YES (ver 2.2.1)
  
  --     FFMPEG:                      YES
  
  --       codec:                     YES (ver 56.1.0)
  
  --       format:                    YES (ver 56.1.0)
  
  --       util:                      YES (ver 54.3.0)
  
  --       swscale:                   YES (ver 3.0.0)
  
  --       gentoo-style:              YES
  
  --     GStreamer:                   NO
  
  --     OpenNI:                      NO
  
  --     OpenNI PrimeSensor Modules:  NO
  
  --     PvAPI:                       NO
  
  --     GigEVisionSDK:               NO
  
  --     UniCap:                      NO
  
  --     UniCap ucil:                 NO
  
  --     V4L/V4L2:                    Using libv4l1 (ver 1.2.1) / libv4l2 (ver 1.2.1)
  
  --     XIMEA:                       NO
  
  --     Xine:                        NO
  
  -- 
  
  --   Other third-party libraries:
  
  --     Use IPP:                     NO
  
  --     Use Eigen:                   YES (ver 3.2.1)
  
  --     Use TBB:                     YES (ver 4.2 interface 7000)
  
  --     Use OpenMP:                  NO
  
  --     Use GCD                      NO
  
  --     Use Concurrency              NO
  
  --     Use C=:                      NO
  
  --     Use Cuda:                    NO
  
  --     Use OpenCL:                  YES
  
  -- 
  
  --   OpenCL:
  
  --     Version:                     dynamic
  
  --     Include path:                /home/keeda/Downloads/data_analysis/opencv-2.4.11/3rdparty/include/opencl/1.2
  
  --     Use AMD FFT:                 NO
  
  --     Use AMD BLAS:                NO
  
  -- 
  
  --   Python:
  
  --     Interpreter:                 /usr/bin/python2 (ver 2.7.8)
  
  --     Libraries:                   /usr/lib/i386-linux-gnu/libpython2.7.so (ver 2.7.8)
  
  --     numpy:                       /usr/local/lib/python2.7/dist-packages/numpy/core/include (ver 1.9.1)
  
  --     packages path:               lib/python2.7/dist-packages
  
  -- 
  
  --   Java:
  
  --     ant:                         /usr/bin/ant (ver 1.9.4)
  
  --     JNI:                         /usr/lib/jvm/default-java/include /usr/lib/jvm/default-java/include /usr/lib/jvm/default-java/include
  
  --     Java tests:                  YES
  
  -- 
  
  --   Documentation:
  
  --     Build Documentation:         YES
  
  --     Sphinx:                      /usr/bin/sphinx-build (ver 1.2.2)
  
  --     PdfLaTeX compiler:           /usr/bin/pdflatex
  
  --     Doxygen:                     NO
  
  -- 
  
  --   Tests and samples:
  
  --     Tests:                       YES
  
  --     Performance tests:           YES
  
  --     C/C++ Examples:              YES
  
  -- 
  
  --   Install path:                  /usr/local
  
  -- 
  
  --   cvconfig.h is in:              /home/keeda/Downloads/data_analysis/opencv-2.4.11/build
  
  -- -----------------------------------------------------------------

• VP8 Codec Optimization Update

  15 juin 2010, par noreply@blogger.com (John Luther) — inside webm

  Since WebM launched in May, the team has been working hard to make the VP8 video codec faster. Our community members have contributed improvements, but there’s more work to be done in some interesting areas related to performance (more on those below).

  
  

  Encoder

  
  The VP8 encoder is ripe for speed optimizations. Scott LaVarnway’s efforts in writing an x86 assembly version of the quantizer will help in this goal significantly as the quantizer is called many times while the encoder makes decisions about how much detail from the image will be transmitted.

  For those of you eager to get involved, one piece of low-hanging fruit is writing a SIMD version of the ARNR temporal filtering code. Also, much of the assembly code only makes use of the SSE2 instruction set, and there surely are newer extensions that could be made use of. There are also redundant code removal and other general cleanup to be done ; (Yaowu Xu has submitted some changes for these).
  
  At a higher level, someone can explore some alternative motion search strategies in the encoder. Eventually the motion search can be decoupled entirely to allow motion fields to be calculated elsewhere (for example, on a graphics processor).
  

  Decoder

  
  Decoder optimizations can bring higher resolutions and smoother playback to less powerful hardware.

  Jeff Muizelaar has submitted some changes which combine the IDCT and summation with the predicted block into a single function, helping us avoid storing the intermediate result, thus reducing memory transfers and avoiding cache pollution. This changes the assembly code in a fundamental way, so we will need to sync the other platforms up or switch them to a generic C implementation and accept the performance regression. Johann Koenig is working on implementing this change for ARM processors, and we’ll merge these changes into the mainline soon.

  In addition, Tim Terriberry is attacking a different method of bounds checking on the "bool decoder." The bool decoder is performance-critical, as it is called several times for each bit in the input stream. The current code handles this check with a simple clamp in the innermost loops and a less-frequent copy into a circular buffer. This can be expensive at higher data rates. Tim’s patch removes the circular buffer, but uses a more complex clamp in the innermost loops. These inner loops have historically been troublesome on embedded platforms.
  
  To contribute in these efforts, I’ve started working on rewriting higher-level parts of the decoder. I believe there is an opportunity to improve performance by paying better attention to data locality and cache layout, and reducing memory bus traffic in general. Another area I plan to explore is improving utilization in the multi-threaded decoder by separating the bitstream decoding from the rest of the image reconstruction, using work units larger than a single macroblock, and not tying functionality to a specific thread. To get involved in these areas, subscribe to the codec-devel mailing list and provide feedback on the code as it’s written.
  

  Embedded Processors

  
  We want to optimize multiple platforms, not just desktops. Fritz Koenig has already started looking at the performance of VP8 on the Intel Atom platform. This platform need some attention as we wrote our current x86 assembly code with an out-of-order processor in mind. Since Atom is an in-order processor (much like the original Pentium), the instruction scheduling of all of the x86 assembly code needs to be reexamined. One option we’re looking at is scheduling the code for the Atom processor and seeing if that impacts the performance on other x86 platforms such as the Via C3 and AMD Geode. This is shaping up to be a lot of work, but doing it would provide us with an opportunity to tighten up our assembly code.
  
  These issues, along with wanting to make better use of the larger register file on x86_64, may reignite every assembly programmer’s (least ?) favorite debate : whether or not to use intrinsics. Yunqing Wang has been experimenting with this a bit, but initial results aren’t promising. If you have experience in dealing with a lot of assembly code across several similar-but-kinda-different platforms, these maintainability issues might be familiar to you. I hope you’ll share your thoughts and experiences on the codec-devel mailing list.
  
  Optimizing codecs is an iterative (some would say never-ending) process, so stay tuned for more posts on the progress we’re making, and by all means, start hacking yourself.
  
  It’s exciting to see that we’re starting to get substantial code contributions from developers outside of Google, and I look forward to more as WebM grows into a strong community effort.
  
  John Koleszar is a software engineer at Google.

  

• VP8 Codec Optimization Update

  16 juin 2010, par noreply@blogger.com (John Luther) — inside webm

  Since WebM launched in May, the team has been working hard to make the VP8 video codec faster. Our community members have contributed improvements, but there’s more work to be done in some interesting areas related to performance (more on those below).

  
  

  Encoder

  
  The VP8 encoder is ripe for speed optimizations. Scott LaVarnway’s efforts in writing an x86 assembly version of the quantizer will help in this goal significantly as the quantizer is called many times while the encoder makes decisions about how much detail from the image will be transmitted.

  For those of you eager to get involved, one piece of low-hanging fruit is writing a SIMD version of the ARNR temporal filtering code. Also, much of the assembly code only makes use of the SSE2 instruction set, and there surely are newer extensions that could be made use of. There are also redundant code removal and other general cleanup to be done ; (Yaowu Xu has submitted some changes for these).
  
  At a higher level, someone can explore some alternative motion search strategies in the encoder. Eventually the motion search can be decoupled entirely to allow motion fields to be calculated elsewhere (for example, on a graphics processor).
  

  Decoder

  
  Decoder optimizations can bring higher resolutions and smoother playback to less powerful hardware.

  Jeff Muizelaar has submitted some changes which combine the IDCT and summation with the predicted block into a single function, helping us avoid storing the intermediate result, thus reducing memory transfers and avoiding cache pollution. This changes the assembly code in a fundamental way, so we will need to sync the other platforms up or switch them to a generic C implementation and accept the performance regression. Johann Koenig is working on implementing this change for ARM processors, and we’ll merge these changes into the mainline soon.

  In addition, Tim Terriberry is attacking a different method of bounds checking on the "bool decoder." The bool decoder is performance-critical, as it is called several times for each bit in the input stream. The current code handles this check with a simple clamp in the innermost loops and a less-frequent copy into a circular buffer. This can be expensive at higher data rates. Tim’s patch removes the circular buffer, but uses a more complex clamp in the innermost loops. These inner loops have historically been troublesome on embedded platforms.
  
  To contribute in these efforts, I’ve started working on rewriting higher-level parts of the decoder. I believe there is an opportunity to improve performance by paying better attention to data locality and cache layout, and reducing memory bus traffic in general. Another area I plan to explore is improving utilization in the multi-threaded decoder by separating the bitstream decoding from the rest of the image reconstruction, using work units larger than a single macroblock, and not tying functionality to a specific thread. To get involved in these areas, subscribe to the codec-devel mailing list and provide feedback on the code as it’s written.
  

  Embedded Processors

  
  We want to optimize multiple platforms, not just desktops. Fritz Koenig has already started looking at the performance of VP8 on the Intel Atom platform. This platform need some attention as we wrote our current x86 assembly code with an out-of-order processor in mind. Since Atom is an in-order processor (much like the original Pentium), the instruction scheduling of all of the x86 assembly code needs to be reexamined. One option we’re looking at is scheduling the code for the Atom processor and seeing if that impacts the performance on other x86 platforms such as the Via C3 and AMD Geode. This is shaping up to be a lot of work, but doing it would provide us with an opportunity to tighten up our assembly code.
  
  These issues, along with wanting to make better use of the larger register file on x86_64, may reignite every assembly programmer’s (least ?) favorite debate : whether or not to use intrinsics. Yunqing Wang has been experimenting with this a bit, but initial results aren’t promising. If you have experience in dealing with a lot of assembly code across several similar-but-kinda-different platforms, these maintainability issues might be familiar to you. I hope you’ll share your thoughts and experiences on the codec-devel mailing list.
  
  Optimizing codecs is an iterative (some would say never-ending) process, so stay tuned for more posts on the progress we’re making, and by all means, start hacking yourself.
  
  It’s exciting to see that we’re starting to get substantial code contributions from developers outside of Google, and I look forward to more as WebM grows into a strong community effort.
  
  John Koleszar is a software engineer at Google.