Recherche avancée

Sur d’autres sites (8728)

• bebop2 modified CV build version of program creates SIGSEGV on raspberry pi 3

  14 mai 2017, par angRyn00b

  I am trying to navigate bebop2 autonomously using raspberry pi 3. I am getting the raw format from bebop2 and decoding it using ffmpeg. It runs completely fine on intel architecture. I tried to cross compile it for arm and it was successful. It runs fine but after a few seconds it crashes and gives SIGSEGV fault. I have tried gdb to bt the problem but it gives an error of memcpy() from /usr/lib/arm-linux-gnuaebihf/libarmmem.so.

  I tried to remove the non-arm instructions dependencies in the first place ; https://raspberrypi.stackexchange.com/questions/29117/process-terminate-with-sigill-using-valgrind/66621#66621

  But then I got an error of memcpy.S no such file or directory.

  I don’t know what to do and I am stuck now.

  [EDIT:1]

  valgrind output :

  valgrind ./Controller
  
  ==1361== Memcheck, a memory error detector
  
  ==1361== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
  
  ==1361== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
  
  ==1361== Command: ./Controller
  
  ==1361== 
  
  ./Controller
  
  ==1361== Invalid read of size 8
  
  ==1361==    at 0x4845004: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361==  Address 0xd1cc50c is 12 bytes inside a block of size 18 alloc'd
  
  ==1361==    at 0x4833970: malloc (vg_replace_malloc.c:263)
  
  ==1361==    by 0xAFC77B3: ??? (in /usr/lib/arm-linux-gnueabihf/libtasn1.so.6.3.2)
  
  ==1361== 
  
  ==1361== Invalid read of size 4
  
  ==1361==    at 0x4845030: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361==  Address 0xd1cc72c is 20 bytes inside a block of size 22 alloc'd
  
  ==1361==    at 0x4833970: malloc (vg_replace_malloc.c:263)
  
  ==1361==    by 0xAFC77B3: ??? (in /usr/lib/arm-linux-gnueabihf/libtasn1.so.6.3.2)
  
  ==1361== 
  
  ==1361== Invalid read of size 8
  
  ==1361==    at 0x484501C: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361==  Address 0xd1ccf9c is 20 bytes inside a block of size 26 alloc'd
  
  ==1361==    at 0x4833970: malloc (vg_replace_malloc.c:263)
  
  ==1361==    by 0xAFC77B3: ??? (in /usr/lib/arm-linux-gnueabihf/libtasn1.so.6.3.2)
  
  ==1361== 
  
  ==1361== Invalid read of size 8
  
  ==1361==    at 0x4844FEC: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361==  Address 0xd1d59ac is 28 bytes inside a block of size 34 alloc'd
  
  ==1361==    at 0x4833970: malloc (vg_replace_malloc.c:263)
  
  ==1361==    by 0xAFC77B3: ??? (in /usr/lib/arm-linux-gnueabihf/libtasn1.so.6.3.2)
  
  ==1361== 
  
  ==1361== Invalid read of size 8
  
  ==1361==    at 0x4844F8C: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361==  Address 0xd1e7a24 is 20 bytes inside a block of size 26 alloc'd
  
  ==1361==    at 0x4833970: malloc (vg_replace_malloc.c:263)
  
  ==1361==    by 0xAFC77B3: ??? (in /usr/lib/arm-linux-gnueabihf/libtasn1.so.6.3.2)
  
  ==1361== 
  
  disInstr(arm): unhandled instruction: 0xEE190F1D
  
                   cond=14(0xE) 27:20=225(0xE1) 4:4=1 3:0=13(0xD)
  
  ==1361== valgrind: Unrecognised instruction at address 0xcc78de8.
  
  ==1361==    at 0xCC78DE8: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0)
  
  ==1361== Your program just tried to execute an instruction that Valgrind
  
  ==1361== did not recognise.  There are two possible reasons for this.
  
  ==1361== 1. Your program has a bug and erroneously jumped to a non-code
  
  ==1361==    location.  If you are running Memcheck and you just saw a
  
  ==1361==    warning about a bad jump, it's probably your program's fault.
  
  ==1361== 2. The instruction is legitimate but Valgrind doesn't handle it,
  
  ==1361==    i.e. it's Valgrind's fault.  If you think this is the case or
  
  ==1361==    you are not sure, please let us know and we'll try to fix it.
  
  ==1361== Either way, Valgrind will now raise a SIGILL signal which will
  
  ==1361== probably kill your program.
  
  ==1361== Invalid read of size 4
  
  ==1361==    at 0x4844BB8: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361==  Address 0xd1eb788 is 48 bytes inside a block of size 50 alloc'd
  
  ==1361==    at 0x4833F2C: operator new(unsigned int) (vg_replace_malloc.c:282)
  
  ==1361==    by 0x77EC9E7: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&amp;) (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.20)
  
  ==1361== 
  
  ==1361== Invalid read of size 4
  
  ==1361==    at 0x4844FA0: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361==  Address 0xd1eb7f0 is 48 bytes inside a block of size 50 alloc'd
  
  ==1361==    at 0x4833F2C: operator new(unsigned int) (vg_replace_malloc.c:282)
  
  ==1361==    by 0x77EC9E7: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&amp;) (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.20)
  
  ==1361== 
  
  disInstr(arm): unhandled instruction: 0xF1010200
  
                   cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
  
  ==1361== valgrind: Unrecognised instruction at address 0x48426f4.
  
  ==1361==    at 0x48426F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361== Your program just tried to execute an instruction that Valgrind
  
  ==1361== did not recognise.  There are two possible reasons for this.
  
  ==1361== 1. Your program has a bug and erroneously jumped to a non-code
  
  ==1361==    location.  If you are running Memcheck and you just saw a
  
  ==1361==    warning about a bad jump, it's probably your program's fault.
  
  ==1361== 2. The instruction is legitimate but Valgrind doesn't handle it,
  
  ==1361==    i.e. it's Valgrind's fault.  If you think this is the case or
  
  ==1361==    you are not sure, please let us know and we'll try to fix it.
  
  ==1361== Either way, Valgrind will now raise a SIGILL signal which will
  
  ==1361== probably kill your program.
  
  ==1361== 
  
  ==1361== Process terminating with default action of signal 4 (SIGILL)
  
  ==1361==  Illegal opcode at address 0x48426F4
  
  ==1361==    at 0x48426F4: ??? (in /usr/lib/arm-linux-gnueabihf/libarmmem.so)
  
  ==1361== 
  
  ==1361== HEAP SUMMARY:
  
  ==1361==     in use at exit: 541,641 bytes in 1,173 blocks
  
  ==1361==   total heap usage: 1,980 allocs, 807 frees, 571,016 bytes allocated
  
  ==1361== 
  
  ==1361== LEAK SUMMARY:
  
  ==1361==    definitely lost: 0 bytes in 0 blocks
  
  ==1361==    indirectly lost: 0 bytes in 0 blocks
  
  ==1361==      possibly lost: 410,404 bytes in 190 blocks
  
  ==1361==    still reachable: 131,237 bytes in 983 blocks
  
  ==1361==         suppressed: 0 bytes in 0 blocks
  
  ==1361== Rerun with --leak-check=full to see details of leaked memory
  
  ==1361== 
  
  ==1361== For counts of detected and suppressed errors, rerun with: -v
  
  ==1361== ERROR SUMMARY: 24 errors from 7 contexts (suppressed: 0 from 0)
  
  Illegal instruction
  
  </char></char>

  bt output :

  (gdb) bt 
  
  #0 0x76fbc3a0 in memcmp () from /usr/lib/arm-linux-gnueabihf/libarmmem.so 
  
  #1 0x00000000 in ?? ()

  disassemble output (0x76fbc3a0) :

  => 0x76fbc3a0 <+7344>:  vldmiacs    r1!, {d7}

  x/5i $pc output :

  (gdb) x/5i $pc
  
  => 0x76fbc3a0 :    vldmiacs    r1!, {d7}
  
     0x76fbc3a4 :    vstmiami    r0!, {s13}
  
     0x76fbc3a8 :    vstmiacs    r0!, {d7}
  
     0x76fbc3ac :    lsls    lr, r12, #27
  
     0x76fbc3b0 :    vldmiami    r1!, {d2-d3}

• I can't use HW encoder of QSV by ffmpeg

  6 novembre 2017, par Ubunkun

  I would like to use to encode by Intel H/W encode QSV.

  Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz

  lspci -nn -s 0:02.0
  00:02.0 VGA compatible controller [0300] : Intel Corporation Broadwell-U Integrated Graphics [8086:1626] (rev 09)

  I could install MediaServerStudioEssentials2017R2 and ffpemg.

  # vainfo | grep -v 'unknown'
  
  error: can't connect to X server!
  
  libva info: VA-API version 0.99.0
  
  libva info: va_getDriverName() returns 0
  
  libva info: User requested driver 'iHD'
  
  libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.so
  
  libva info: Found init function __vaDriverInit_0_32
  
  libva info: va_openDriver() returns 0
  
  vainfo: VA-API version: 0.99 (libva 1.67.0.pre1)
  
  vainfo: Driver version: 16.5.1.59511-ubit
  
  vainfo: Supported profile and entrypoints
  
        VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  
        VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  
        VAProfileH264Main               : VAEntrypointVLD
  
        VAProfileH264Main               : VAEntrypointEncSlice
  
        VAProfileH264High               : VAEntrypointVLD
  
        VAProfileH264High               : VAEntrypointEncSlice
  
        VAProfileMPEG2Simple            : VAEntrypointEncSlice
  
        VAProfileMPEG2Simple            : VAEntrypointVLD
  
        VAProfileMPEG2Main              : VAEntrypointEncSlice
  
        VAProfileMPEG2Main              : VAEntrypointVLD
  
        VAProfileVC1Advanced            : VAEntrypointVLD
  
        VAProfileVC1Main                : VAEntrypointVLD
  
        VAProfileVC1Simple              : VAEntrypointVLD
  
        VAProfileJPEGBaseline           : VAEntrypointVLD
  
        VAProfileJPEGBaseline           : VAEntrypointEncPicture
  
        VAProfileVP8Version0_3          : VAEntrypointEncSlice
  
        VAProfileVP8Version0_3          : VAEntrypointVLD
  
        VAProfileNone                   : VAEntrypointVideoProc

  and

  # ffmpeg -codecs | grep qsv
  
  ffmpeg version N-86584-g4976a34 Copyright (c) 2000-2017 the FFmpeg developers
  
    built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-11)
  
    configuration: --enable-libmfx
  
    libavutil      55. 66.100 / 55. 66.100
  
    libavcodec     57. 99.100 / 57. 99.100
  
    libavformat    57. 73.100 / 57. 73.100
  
    libavdevice    57.  7.100 / 57.  7.100
  
    libavfilter     6. 94.100 /  6. 94.100
  
    libswscale      4.  7.101 /  4.  7.101
  
    libswresample   2.  8.100 /  2.  8.100
  
   DEV.LS h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_qsv h264_cuvid ) (encoders: h264_nvenc h264_qsv h264_vaapi nvenc nvenc_h264 )
  
   DEV.L. hevc                 H.265 / HEVC (High Efficiency Video Coding) (decoders: hevc hevc_qsv hevc_cuvid ) (encoders: nvenc_hevc hevc_nvenc hevc_qsv hevc_vaapi )
  
   DEV.L. mpeg2video           MPEG-2 video (decoders: mpeg2video mpegvideo mpeg2_qsv mpeg2_cuvid ) (encoders: mpeg2video mpeg2_qsv mpeg2_vaapi )
  
   D.V.L. vc1                  SMPTE VC-1 (decoders: vc1 vc1_qsv vc1_cuvid )
  
   DEV.L. vp8                  On2 VP8 (decoders: vp8 vp8_cuvid vp8_qsv ) (encoders: vp8_vaapi )

  But, I tried to encode as below.

  # ffmpeg -i test.avi -c:v h264_qsv -b:v 2000k -r 30 -s 720x480 -acodec copy -look_ahead 0 qsv.mp4
  
  ・・・
  
  [h264_qsv @ 0x3139f40] No device available for encoder (device type qsv for codec h264_qsv).
  
  [h264_qsv @ 0x3139f40] Encoder will work with partial HW acceleration
  
  [h264_qsv @ 0x3139f40] Warning in encoder initialization: partial acceleration (4)
  
  ・・・

  It seems like that the encoding is using by software. It’s slow.
  How can I do by H/W encode ? If you know it, let me know it.

  Bests,

• Hardware decoding using vaapi [on hold]

  15 août 2017, par Orient

  I am trying to replicate hardware decoding using vaapi. My ultimate goal is to get an OpenGL texture wich I whant to get from a vasurface buffer.

  I took as a base https://github.com/gbeauchesne/ffvademo/tree/master/src
  which looks less intimidating than other examples. My initial understanding was that packets were somehow rendered to surfaces (render targets) and at the same time got converted. But it looks like the loop after some nested calls boils down to avcodec_decode_video2 (app_decode_frame -> ffva_decoder_get_frame -> decoder_get_frame -> decoder_run -> decode_packet -> avcodec_decode_video2), which in turn would call codec->decode. So it resembles the way decoding is done on CPU.

  Could anybody explain why this whoud be considered hw decoding ?