Recherche avancée

Sur d’autres sites (3653)

• ffmpeg resulting bitrate higher than expected. did i miss something ? [migrated]

  7 octobre 2013, par zantafio

  i am using ffmpeg to create some h264 transport streams.
  the bitrate for video is 496k, for audio 64k.
  However when the ( 2-pass ) encoding is done, i get a stream with more then 600k.
  i am using the following syntax in my script :

  codec=h264
  
  streamsuffix=ts
  
  audiocutoff=15000
  
  audioprofile=aac_low
  
  audiosamplerate=48000
  
  video_med=496k
  
  audio_med=64k
  
  suffix_med=_med
  
  preset=veryslow
  
  threads=4
  
  dirname="${1%/*}"
  
  filename=$(basename "$1")
  
  extension="${filename##*.}"
  
  filename="${filename%.*}"
  
  
  
  ffmpeg -i $filename"."$extension -preset $preset -strict experimental -threads $threads -c:v $codec -b:v $video_med -bsf:v h264_mp4toannexb -pass 1 -an -f rawvideo -y /dev/null 
  
  ffmpeg -y -i $filename"."$extension -preset $preset -strict experimental -threads $threads -c:a aac -cutoff $audiocutoff -profile:a $audioprofile -b:a $audio_med -ar $audiosamplerate  -c:v $codec -b:v $video_med -bsf:v h264_mp4toannexb -pass 2 $filename$suffix_med"."$streamsuffix

  did i miss something ? do i need to enforce the target bitrate ?
  thanks a lot !

• 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}

• ffmpeg Concatention - negative pad values

  15 décembre 2015, par mmmyum

  I’m relatively new to ffmpeg and having an issue concatenating some videos.

  Occasionally, I’m running into an issue with my command that is producing negative pad values, preventing the concat from completing. Check out this gist for details and the command output.

  Brief summary is that I’m using filter_complex to scale down and/or pad videos. You can see the full commands in the above links, but here are examples of the filter text :

  [$count:v]scale=if(gt(ih\,iw)\,-2\,$VID_WIDTH):if(gt(ih\,iw)\,$VID_HEIGHT\,-2),pad=$VID_WIDTH:$VID_HEIGHT:(ow-iw)/2:(oh-ih)/2,setsar=sar=1/1[v$count];

  where $VID_WIDTH and $VID_HEIGHT are the smallest dimensions of the inputs.

  I’m concatenating hundreds of videos (in different groups), the vast majority of which work without issue - but occasionally I run into this negative pad values issue. I assume it’s because the input width/height is larger than the output width/height, so it produces a negative value, but I’m not sure how to fix this - I need the videos to be centered.

  Other details :

  • most videos are shot on a cell phone, in a portrait orientation (some in landscape, but I’d like to stitch them in portrait anyways)

  • very rarely I run into a video rotated 90 degrees (larger width than height) - not sure how I should handle this, but one issue at a time

  • usually all videos have the same dimensions, but occasionally one or more videos in a group will have slightly different dimensions, sometimes just by a couple pixels (see attached gist for example)

  • scripting everything in bash right now