bthomas's profile - activity

Hi

Trying to open and read the Megamind.avi video using OpenCV 3.2 causes a segmentation fault. Is this a known problem or is the simple C++ program below in error (if so I would appreciate any pointers on what the issue may be) :

Steps to reproduce :

• Platform : Mac OS X 10.12.4
• Compiler : Clang++ (LLVM version 8.1.0 [clang-802.0.42])
• OpenCV : 3.2.0 installed from macports using command line "port install opencv +contrib +eigen +opencl +python27 +qt5"
• FFmpeg : 3.3.3 installed from macports (any variant)
• Video : Megamind.avi from http://docs.opencv.org/3.2.0/d5/dc4/t... This video is playable using "ffplay" provided by the installed FFmpeg
• Installed OpenCV 3.2.0 has been compiled with FFmpeg enabled (The opencv2/cvconfig.h file has "#define HAVE_FFMPEG" uncommented).

• Simple test C++ program (given below)

  #include <iostream>
  #include <opencv2/core.hpp>
  #include <opencv2/videoio.hpp>
  int main(void)
  {
      try 
      {
          cv::VideoCapture video("Megamind.avi", cv::CAP_FFMPEG);
          if(!video.isOpened()) throw std::runtime_error("Could not open video");
       }
      catch (cv::Exception &e)
      {
          std::cout << e.what() << std::endl;
      }
      return 0;
   }
  

• Stack trace of segmentation fault (given below)

   (lldb) target create "./scratch"
   Current executable set to './scratch' (x86_64).
   (lldb) r 
   Process 21181 launched: './scratch' (x86_64)
   Process 21181 stopped
   * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
           frame #0: 0x000000010474f962 libavutil.55.dylib`av_buffer_unref + 18
   libavutil.55.dylib`av_buffer_unref:
  ->  0x10474f962 <+18>: movq   (%rax), %rbx
       0x10474f965 <+21>: movq   %rbx, 0x8(%rsp)
       0x10474f96a <+26>: callq  0x1047630e0               ; av_freep
       0x10474f96f <+31>: movl   $0xffffffff, %eax         ; imm = 0xFFFFFFFF 
  (lldb) bt
  * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
      * frame #0: 0x000000010474f962 libavutil.55.dylib`av_buffer_unref + 18
        frame #1: 0x000000010475ac8a libavutil.55.dylib`av_frame_unref + 346
        frame #2: 0x00000001018878bd libopencv_videoio.3.2.dylib`CvCapture_FFMPEG::close() + 127
        frame #3: 0x0000000101887aac libopencv_videoio.3.2.dylib`CvCapture_FFMPEG::open(char const*) + 42
        frame #4: 0x0000000101889a33 libopencv_videoio.3.2.dylib`cvCreateFileCapture_FFMPEG + 259
        frame #5: 0x000000010188a82b libopencv_videoio.3.2.dylib`CvCapture_FFMPEG_proxy::open(char const*) + 45
        frame #6: 0x000000010188a4f1 libopencv_videoio.3.2.dylib`cvCreateFileCapture_FFMPEG_proxy(char const*) + 52
        frame #7: 0x000000010187dd34 libopencv_videoio.3.2.dylib`cvCreateFileCaptureWithPreference + 169
        frame #8: 0x000000010187ebd6 libopencv_videoio.3.2.dylib`cv::VideoCapture::open(cv::String const&, int) + 292
        frame #9: 0x000000010187e765 libopencv_videoio.3.2.dylib`cv::VideoCapture::VideoCapture(cv::String const&, int) + 51
        frame #10: 0x0000000100001dc9 scratch`main at scratch.cpp:9
        frame #11: 0x00007fffa2ead235 libdyld.dylib`start + 1
  

• I have searched this forum and Google but have not been able to find a resolution to the problem. In view of the above it does not seem to be a Codec issue. I have checked that it is not related to paths (absolute/relative) etc. Using "cv::CAP_ANY" instead of cv::CAP_FFMPEG", or even not setting this property, does not fix the problem either.