Recherche avancée

Sur d’autres sites (6480)

• Use Video stream from Wifi device as input to stream over 4G

  1er mars 2017, par pbdev

  I’m building an Android app that streams video from a Wifi device to a Wowza server. It should be quite simple but I can’t figure out how to use both Wifi and 4G at the same time. The device I’m using is a Samsung S5 with Android 6.0.1. To sum it up, this is the goal :

  1. Fetch the video stream from a GoPro device over Wifi.
  2. Send the video stream to a Wowza server over 4G.

  When connected to the GoPro’s Wifi network I can ping the GoPro and see the stream in a MediaPlayer. Since I’m connected to a Wifi device that doesn’t provide internet access, I can’t ping my Wowza server. Once I’ve disabled Wifi this is no problem, by using FFmpeg I can reach the Wowza server over 4G.

  This is the FFmpeg command I want to use to copy the stream to the Wowza server, where 10.5.5.9 is the IP-address of the GoPro :

  ffmpeg -i http://10.5.5.9:8080/live/amba.m3u8 -acodec aac -ar 44100 -ab 48k -vcodec copy -f flv rtmp://username:password@my-wowza-server.com:1935/my-app/my-stream

  If I enable Wifi and connect to the GoPro, 10.5.5.9 is reachable but my-wowza-server.com isn’t. The Samsung S5 provides a Smart network switch which makes the Wowza server reachable but the connection to the GoPro gets lost.

  Is there any way to bind 10.5.5.9 to the Wifi interface of the phone and bind my-wowza-server.com to the cellular interface ?

• ffmpeg streaming at less than 1x speed [closed]

  14 juin 2023, par Rebhu Johymalyo Josh

  When trying to stream ffmpeg hevc codec from rtsp feed to output std pipe in PyQT, ffmpeg speed drops for couple of streams out of 4 to .4x .6x while others have speed of 1.01x.
Any reason this would happen and how to mitigate it ?

  


  FFMPEG stream command

  


  ffmpeg -rtsp_transport tcp -i "rtsp://admin:password@192.168.0.94:554/cam/realmonitor?channel=1&subtype=0" -vf "mpdecimate,setpts=N/FRAME_RATE/TB,fps=25" -vsync vfr -tune zerolatency -fflags nobuffer -s 1920x1080 -f rawvideo -pix_fmt rgb24 -loglevel quiet -report pipe:1

  


  I tried adding the -vf parameter to drop duped frames but to no rescue.

  


  Logs below :

  


  Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24(pc, gbr/unknown/unknown, progressive), 1920x1080, q=2-31, 1244160 kb/s, 25 fps, 25 tbn
    Metadata:
      encoder         : Lavc58.134.100 rawvideo
frame=    1 fps=0.0 q=-0.0 size=    6075kB time=00:00:00.04 bitrate=1244160.0kbits/s speed=0.625x    
frame=    2 fps=0.2 q=-0.0 size=   12150kB time=00:00:00.08 bitrate=1244160.0kbits/s speed=0.00912x    
frame=    4 fps=0.4 q=-0.0 size=   24300kB time=00:00:00.16 bitrate=1244160.0kbits/s speed=0.0165x    
frame=    6 fps=0.6 q=-0.0 size=   36450kB time=00:00:00.24 bitrate=1244160.0kbits/s speed=0.0228x    
frame=    7 fps=0.6 q=-0.0 size=   42525kB time=00:00:00.28 bitrate=1244160.0kbits/s speed=0.0249x    


  


• AppRTC : Google’s WebRTC test app and its parameters

  23 juillet 2014, par silvia

  If you’ve been interested in WebRTC and haven’t lived under a rock, you will know about Google’s open source testing application for WebRTC : AppRTC.

  When you go to the site, a new video conferencing room is automatically created for you and you can share the provided URL with somebody else and thus connect (make sure you’re using Google Chrome, Opera or Mozilla Firefox).

  We’ve been using this application forever to check whether any issues with our own WebRTC applications are due to network connectivity issues, firewall issues, or browser bugs, in which case AppRTC breaks down, too. Otherwise we’re pretty sure to have to dig deeper into our own code.

  Now, AppRTC creates a pretty poor quality video conference, because the browsers use a 640×480 resolution by default. However, there are many query parameters that can be added to the AppRTC URL through which the connection can be manipulated.

  Here are my favourite parameters :
  

  • hd=true : turns on high definition, ie. minWidth=1280,minHeight=720
  • stereo=true : turns on stereo audio
  • debug=loopback : connect to yourself (great to check your own firewalls)
  • tt=60 : by default, the channel is closed after 30min – this gives you 60 (max 1440)

  For example, here’s how a stereo, HD loopback test would look like : https://apprtc.appspot.com/?r=82313387&hd=true&stereo=true&debug=loopback .

  This is not the limit of the available parameter, though. Here are some others that you may find interesting for some more in-depth geekery :

  • ss=[stunserver] : in case you want to test a different STUN server to the default Google ones
  • ts=[turnserver] : in case you want to test a different TURN server to the default Google ones
  • tp=[password] : password for the TURN server
  • audio=true&video=false : audio-only call
  • audio=false : video-only call
  • audio=googEchoCancellation=false,googAutoGainControl=true : disable echo cancellation and enable gain control
  • audio=googNoiseReduction=true : enable noise reduction (more Google-specific parameters)
  • asc=ISAC/16000 : preferred audio send codec is ISAC at 16kHz (use on Android)
  • arc=opus/48000 : preferred audio receive codec is opus at 48kHz
  • dtls=false : disable datagram transport layer security
  • dscp=true : enable DSCP
  • ipv6=true : enable IPv6

  AppRTC’s source code is available here. And here is the file with the parameters (in case you want to check if they have changed).

  Have fun playing with the main and always up-to-date WebRTC application : AppRTC.

  UPDATE 12 May 2014

  AppRTC now also supports the following bitrate controls :

  • arbr=[bitrate] : set audio receive bitrate
  • asbr=[bitrate] : set audio send bitrate
  • vsbr=[bitrate] : set video receive bitrate
  • vrbr=[bitrate] : set video send bitrate

  Example usage : https://apprtc.appspot.com/?r=&asbr=128&vsbr=4096&hd=true

  The post AppRTC : Google’s WebRTC test app and its parameters first appeared on ginger’s thoughts.