Recherche avancée

Sur d’autres sites (4632)

• sdp : Add an option for sending RTCP packets to the source of the last packets

  13 août 2013, par Martin Storsjö

  sdp : Add an option for sending RTCP packets to the source of the last packets
  An SDP description normally only contains the target IP address
  
  and port for the packets. This means that we don’t really have
  
  any clue where to send the RTCP RR packets - previously they’re
  
  sent to the destination IP written in the SDP (at the same port),
  
  which rarely is the actual peer. And if the source for the packets
  
  is on a different port than the destination, it’s never correct.
  With a new option, we can choose to send the packets to the
  
  address that the latest packet on each socket arrived from.
  
  — -
  
  Some may even argue that this should be the default - perhaps,
  
  but I’d rather keep it optional at first. Additionally, I’m not
  
  sure if sending RTCP RR directly back to the source is
  
  desireable for e.g. multicast.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavformat/rtsp.c
  • [DBH] libavformat/rtsp.h

• FFMPEG - Streaming multiple video files to RTMP server [closed]

  17 janvier 2021, par JackCisco

  I am using Ubuntu 20.0.4

  



  What I want to achieve is using FFMPEG to stream many video files of different codecs and resolutions to my RTMP server one after the other. These files can be for example avi, mp4, mkv. All with seamless playback.

  



  So far I've managed to optimise the playback of a single video using the following command :

  



  ffmpeg -re -i video.mp4 -r 30 -preset medium -force_key_frames 'expr:gte(t,n_forced*4)' -g 120 -keyint_min 120 -acodec aac -vcodec libx264 -b:v 1M -b:a 192k -f flv rtmp://address/live/live


  



  Succeeding with that I then proceeded to attempt to use concat to read a list of files from a .txt file and play them one after the other, which looks like this :

  



  file '/pathtovideo/video1.mp4'
file '/pathtovideo/video2.avi'
file '/pathtovideo/video3.mkv'


  



  What I've ended up with below works well for the first file played, but there's a nice bit of pausing and freezing during playback before I start to see the next video, which has out of sync audio and video :

  



  ffmpeg -re -safe 0 -f h264 -f concat -segment_time_metadata 1 -i "videos.txt" -vf select=concatdec_select -af aselect=concatdec_select,aresample=async=1 -r 30 -preset medium -tune animation -force_key_frames 'expr:gte(t,n_forced*4)' -g 120 -keyint_min 120 -acodec aac -vcodec libx264 -b:v 1M -b:a 192k -f flv rtmp://address/live/live


  



  When the new video file starts, I notice the output of FFMPEG stops increasing the frames processed for about 5 seconds.

  



  Essentially the outcome is a poor transition between videos and lots of playback freezing on any proceeding video after the first.

  



  I'm a bit lost as to what to do to improve this, so any help is appreciated.

  


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