Recherche avancée

Sur d’autres sites (4793)

• Playing RDT (Real Data Transport) through FFmpeg without SDP file

  24 février 2021, par William Seemann

  I'm doing some research into how Roku delivers their private listening stream. I believe the RTSP stream is delivered via RDT and I'm able to view the packets in Wireshark. I can't play the stream using FFmpeg despite it supporting RDT/RTSP because a SDP file is required. Is it possible to generate this SDP file or play the stream without one ?

  


• Minimal "hello world" for WebRTC real-time streaming ?

  4 novembre 2018, par d33tah

  I’d like to learn about how to set up HTML5 live streaming. The use case I have in mind is related to controlling a Lego Mindstorms robot, which means that I want minimal latency. So far I experimented with RTMP using this Docker repository, but found that I can’t seem to tune it to get a real-time streaming. After a bit of research, I found that WebRTC could perhaps fit my use case.

  Let’s say I have a ffmpeg-compatible source, such as a webcam or x11grab data that I would like to stream using WebRTC. What would a "hello, world" look like that achieves this goal ?

• FFMPEG H.264 to JPEG for real time video

  18 juillet 2017, par Joe Quinn

  Any help appreciated.

  We are trans-coding H.264 streams into Jpgs which are sending across a web socket to the browser. The reason we are looking to do this is so we can deliver real time video to a browser natively. No need for plugins in a browser agnostic way. If there is a better way to do this then it would be great to know more. The Videos source are H.264 though and we cant change that.

  As we lower the FPS we are seeing a greater lag in the camera video feed. e.g at 1 FPS we see the video in the browser is 8 seconds behind. at 15 FPS the video is about 1 second behind. So even though at 1 FPS it updates every second the frame is 8 seconds behind.

  We think this is because FFMPEG with the lower frame rate has to wait longer for an I Frame and wont send a Jpeg to the web socket until it has a complete one. We would rather it sends a the Jpeg without having to wait till the IFrame arrives, we would rather see a partial image that gradually gets filled in on the browser. We cannot tolerate a lag of greater than 0.8 seconds in the browser. When the cameras are set to send MJPEG we see 0.250 seconds lag. With H.264 we see 1.25 seconds and we need to get that down to 0.8 seconds. So we really are looking to fine tune H.264 to shave off some time. That’s why when our first approach to lower the FPS made things worse we were surprised so wondering what else needs to be fine tuned in step with the FPS to get a good result.

  Is there any option to FFMPEG that tells it to send Jpegs as soon as the first piece of data arrives ? OR maybe we should look at other tuning avenues ?

  Here are the FFMPEG parameters :
  ffmpeg
   buffer_size 1024000
   r 15
   i rtsp ://10.140.150.92/02441987-0826-4dc2-b9bd-62efdc0dd951/02441987-0826-4dc2-b9bd-62efdc0dd951_vs1 ?token=02441987-0826-4dc2-b9bd-62efdc0dd951^LVEAMOKTD^100^40^26^1500482113^a97effd2a6f85c4a0b5e93953b27c8e1eb40ca77&username=USER1
   f image2
   multiple_requests 1
   icy 0
   chunked_post 0
   q:v 31
   vsync 1
   r 15
   vf scale=640 :-1
  http://127.0.0.1:58014/video/cameraTag_deviceId_22cameraUid_-1scale_640 :-1cameraOrigin_requestedStreams_videostream1/frame-%03d.jpeg

  Many Thanks,
  Joe.