Recherche avancée

Sur d’autres sites (8595)

• ffmpeg udp/tcp stream receive frame not same as sent

  21 novembre 2013, par vivienlwt

  I am streaming a video on raspberrypi using command :

  ffmpeg -re -threads 2 -i sample_video.m2v -f mpegts - | \
  
  ffmpeg -f mpegts -i - -c copy -f mpegts udp://192.168.1.100:12345

  The remote PC with 192.168.1.100 uses ffmpeg library to listen to the input stream. For example :

  informat = ffmpeg::av_find_input_format("mpegts");
  
  avformat_open_input(&pFormatCtx, "udp://192.168.1.100:12345", informat, options);

  However, when I compute the hash value of each decoded frame on two sides (i.e. raspberrypi and PC), they DON'T MATCH at all. A weird thing is, among 2000 frames, there are in total 10 frames whose hash value are the same on the sender and receiver side. The match result look like this :

  00000....00011000...00011110000...000

  where 0 indicates non-match and 1 indicates match. The matched frame appeared 2 6 in sequence and appeared rarely while most of the other frames has different hash value.

  The hash is computed on the frame data buffer extracted using avpicture_layout(). On the Pi side, I just stream the video to a local port and there's a local process using the same code to decode and hash the frames :

  ffmpeg -re -threads 2 -i sample_video.m2v -f mpegts - | \
  
  ffmpeg -f mpegts -i - -c copy -f mpegts udp://localhost:12345
  
  ...

  The streaming source raspberry pi, is connected directly to the PC using cable. I don't think it is a packet loss problem. Because, first, I rerun the same process several times and the hash value of the received frames are the same (otherwise the result should be different because packet loss is probabilistic). Secondly, I even try to stream on tcp ://192.168.1.100:12345 (and "tcp ://192.168.1.100:12345 ?listen" on PC), and the received frame hash are still the same - different than the hash result on the Pi.

  So, does anyone know why the streaming to a remote address will yield different decoded frames ? Maybe I am missing some details.

  Thanks in advance !!

• Possible to stream video over 115kbps ?

  15 mai 2014, par Arcadio Alivio Sincero

  I need some advice from people experienced with streaming video.

  I have a task to put together a system that allows video coming from RS-170 (composite) video cameras and have them displayed on an iPad. The catch is that no wireless (no Wi-Fi, no bluetooth) is allowed. Only a wired interface.

  The physical I/O options on an iPad are apparently extremely limited, but I did manage to come across a company named Redpark that makes an RS232-to-Lightning cable. So my proposed solution is to have the video feeds go into a box with software that digitizes and encodes the video, and then sends it over RS232 to the iPad using that cable. The catch here is that the maximum bandwidth on that cable is 115kbps.

  My preliminary testing of this setup on a prototype system have been less than stellar so far. I set up two PCs, each with serial ports, and hooked them together with a null modem. I then set the baud rates of the ports to 115kpbs and then attempted to stream a web cam video feed over the serial connection in real-time using ffmpeg. The results weren’t very encouraging, but I at least did manage to get some sort of image to show up.

  I guess I need to play around with the ffmpeg encoding options some more. But I need to ask : am I wasting my time with this idea, or should what I am asking here be possible ?

• How to prevent ffmpeg from crashing if UDP target is unreachable

  17 décembre 2014, par sg90

  I am using ffmpeg to capture an input video feed from a capture device, save to disk, and relay the feed via udp to a host machine. When the network is down, i.e. an unplugged cable, or faulty switch, or the host is down, ffmpeg crashes with :

  [mpeg1video @ 0x2fdcb20] ignoring invalid SAR: 0/0
Last message repeated 38 times
av_interleaved_write_frame(): Network is unreachable
frame=  758 fps= 25 q=1.0 size=     616kB time=00:00:30.24 bitrate= 166.7kbits/sframe=  758 fps= 25 q=1.0 Lsize=     616kB time=00:00:30.24 bitrate= 166.7kbits/s<br />
video:616kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
Conversion failed!

  When the network crashes, this also crashes the saving to disk. Unfortunately my capture device cannot handle multiple simultaneous access so I can’t split this into two processes (easily).

  I would like to make the UDP streaming fault tolerant to continue trying to stream the next frame if it can’t send any packets. As UDP is "fire and forget", I am quite surprised this already isn’t the default behaviour - I’d even expect HTTP streaming to do the same without crashing. Surely this has happened to other ffmpeg users ?

  Is there a flag I can set to continue/ignore the "Network is unreachable" exception thrown ?

  I’d like to do this without making a custom build of ffmpeg, but if anyone has tried this before I would appreciate any pointers.

  Thanks