Recherche avancée

Sur d’autres sites (8284)

• Support broadcast destination for udp protocol

  9 avril 2014, par Olivier Langlois

  Support broadcast destination for udp protocol
  Use the required socket option SO_BROADCAST to be able to stream to a broadcast
  
  address.
  Prior to the patch, trying to stream to a broadcast address was resulting to the
  
  following error :
  av_interleaved_write_frame() : Permission denied
  The patch has been tested with :
  ffmpeg -f v4l2 -framerate 30 -input_format yuyv422 -video_size 640x480 -i /dev/video0 \
  
   -c:v libx264 -profile:v high -preset ultrafast -tune zerolatency -b:v 500k -pix_fmt yuv420p \
  
   -f mpegts udp ://192.168.1.255:5004 ?broadcast=1
  I have added an option to let the user explicitly request broadcast in order to avoid
  
  ffmpeg to broadcast unintentionally.
  Signed-off-by : Olivier Langlois <olivier@trillion01.com>
  
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavformat/udp.c

• Path to publish FFMPEG video files to Azure Blob Storage ?

  25 janvier 2016, par CG-Guy

  Please kindly help me get out of a bad situation with a very very unhappy client. I am using FFMPEG based app to publish video files to Azure Blob storage, but the files are not going through the network. FFMPEG app has full access to firewall ports. FFMPEG communication shell show files are published without errors. A look at TCP connections shows the app is making connection with Azure account remote address 104.208.XXX.XX and remote port 443. However, it drops the connection and starts repeating attempts over and over. It will then time out after countless attempts and crash the app. Here is my publish point. Is this the correct publish point for this kind of connection ? What is the proper connection string ? :

  https://account-name.blob.core.windows.net/video/video.flv /DestKey :account-storage-key

  I have also tried http:// without success. Same thing happens. It attempts connecting to remote address and port 80. Again, after several attempts it will timeout and crash. System is a Server 2008 R2 unit on-site, not VM. Your help is much appreciated. Thanks a lot !

• FFMPEG streaming chunk error over RTSP

  5 février 2015, par blackibiza

  I’m using an IP Camera connected over Gigabit-Ethernet which can stream the live image over RTSP.
  I’ve tried many combinations of ffmpeg and ffplay without success.

  So far, if I run vlc and open the rtsp :// address, the image comes up, but in the terminal I can read a lot of messages like :

  [mjpeg @ 0x7f70ac034d80] Found EOI before any SOF, ignoring
  
  [mjpeg @ 0x7f70ac034d80] No JPEG data found in image

  while, if I use ffplay or ffmpeg, I get no images but a lot of these messages :

  Last message repeated 33 times
  
  [rtsp @ 0x7f5c68f285a0] Reserved q value 100
  
  [rtsp @ 0x7f5c68f285a0] Received packet without a start chunk; dropping frame.

  The IP camera supports only UDP streaming, if I try to force the TCP streaming, It doesn’t start at all, saying :

  [rtsp @ 0x7f019a5de720] Nonmatching transport in server reply
  
  Invalid data found when processing input

  I’ve used also wireshark to dump the packets and see the differences between VLC and FFMPEG tools, but they are identical, so I don’t understand why VLC can still retrieve the jpeg data from this RTSP stream.

  I’m using the latest ffmpeg package available on ArchLinux.
  What could be the problem and how could I access the mjpeg image sent over the RTSP ?
  Due this FFMPEG problem, the cv::VideoCapture function of OpenCV is returning the same error of ffplay and ffmpeg tools.

  Thanks in advance

  Update :

  using the following command :

  cvlc -vvv rtsp://172.23.23.124 --noaudio --sout '#standard{access=http,mux=mpjpeg,dst=127.0.0.1:8080}'

  I’m now able to play even with ffplay the stream, but only if I use the -f mjpeg option.
  How can I force now OpenCV to access the same http address, which works with ffplay, and get the MJPEG image ? Opening VideoCapture with the address only isn’t working.