Recherche avancée

Sur d’autres sites (3790)

• 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

• 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

• Why is ffmpeg's hstack so much slower than overlay and pad ?

  27 janvier 2021, par cgenco

  I'm using ffmpeg to stitch together two videos of people chatting into a video with each of them side-by-side, like this :

  


  

  


  Here's the command I'm currently using to get this done, which runs at 2.5x on my 13" M1 MacBook Pro :

  


  ffmpeg -y -i left.mp4 -i right.mp4 -filter_complex "
  [0:v] crop=w=in_w/2 [croppedLeft];
  [1:v][1:v] overlay=x=overlay_w/4 [shiftedRight];
  [shiftedRight][croppedLeft] overlay [vout];
  [0:a][1:a] amix [aout]
" -map "[vout]" -map "[aout]" -ac 2 out.mp4


  


  This command crops the left video to half of its original width (cropping so the video is centered), then shifts the right video a quarter of its width to the right, then overlays the left video on the left half of the output merged with the shifted right video.

  


  One day on my weekly fun-time read-through the FFmpeg filters documentation I stumbled on a filter named hstack, which is described as being "faster than using overlay and pad filter to create same output."

  


  My ex wife can affirm that there are few higher priorities in my life than going faster, so I altered my ffmpeg script to use hstack instead of two overlays :

  


  ffmpeg -y -i left.mp4 -i right.mp4 -filter_complex "
  [0:v] crop=w=in_w/2 [croppedLeft];
  [1:v] crop=w=in_w/2 [croppedRight];
  [croppedLeft][croppedRight] vstack [vout];
  [0:a][1:a] amix [aout]
" -map "[vout]" -map "[aout]" -ac 2 out.mp4


  


  ...but that command runs painfully slowly, like 0.1x. It takes multiple minutes to render a single second.

  


  So uhhh what's going on here ? Why is hstack taking so long when it's supposed to be faster ?

  


  I've tried this on both the M1 native build from OSXExperts (version N-99816-g3da35b7) and the standard ffmpeg from brew and hstack is just as slow on each.