Skip to content

Kinesis Video Streams with WebRTC stops displaying new frames after a certain point when using TURN

3

I am working on a project that requires sending very large video (about 400kb per frame) at 1fps in as close to real time as possible from a server to one or more web clients. I was able to modify the C SDK sample to send the video with an acceptable latency but am running into a strange issue specifically when using TURN;

After 181 frames the video feed stops displaying new frames.

  • According to nettop the viewer is still receiving the new frames, as the bytes-in continues to rise at the same rate until either the viewer or server is stopped, but the web browser stops displaying them. This was tested with both Google Chrome and Firefox, on both the JS SDK sample and the AWS console video viewer with the same result.
  • The number of frames it displays is not affected by the frame rate, length of the video, or elapsed time. However it does seem to be affected by the size of the frames. If I use a more compressed version of the video (approx. 150kb per frame) the number changes from 181 frames to 505 frames. It does not stop at a consistent total size though, the 181 frame test totals 74.4Mb and the 505 frame test totals 83Mb.
  • This isn't an issue of going over the 5Mbps TURN server quota either, as I am only hitting at most 3Mbps.
  • Disabling NAT traversal and just running the test localhost to localhost causes the issue to disappear, and I am unable to find a consistent setup to test this with STUN.
  • I get no error messages from either end in these tests
  • The videos are h.264 encoded using ffmpeg (CRF 15 ultrafast, 4:2:0) with no audio

I am at a bit of a loss as to how to even debug this issue further. Can anyone provide either a suggestion as to why this might be happening, or other steps I can take to further diagnose this issue?

Edit:

More context. Here is some webrtc-internals data from a different run that got 300 frames in: Pictured: frames received / decoded (in red) vs bytes in (in blue) In this graph frames received / decoded is the red and bytes received is the blue line, you can see that the channel is still receiving data, it just stops decoding it.

and here: Pictured: frames received / decoded (in red) vs packets received (in yellow) vs TOTAL packets lost (in purple) In this graph frames received / decoded is the red, packets received is the yellow line and total packets lost is the purple line. The number of lost packets does not increase significantly after the point the video stops.

1 Answer
0

Hello JosephR, thank you for describing the issue you're experiencing with Kinesis Video Streams with WebRTC where the video feed stops displaying new frames after a certain point, specifically when using TURN. Let's walk through the issue step by step:

Based on the information you've provided, here are some potential causes and solutions to consider (NOTE: Remember to test any changes in a non-production environment first to ensure they don't introduce new issues.)

ICE Connection Timeout: The issue might be related to ICE (Interactive Connectivity Establishment) connection timing out. To address this:

  1. Increase the ICE-related timeouts in your WebRTC configuration.
  2. Adjust the iceConnectionCheckPollingInterval to a higher value.

Network Conditions: Poor network conditions might be affecting the TURN relay. To mitigate this:

  1. Ensure your TURN server has sufficient bandwidth capacity.
  2. Check for any network restrictions or firewalls that might be interfering with the TURN connection.

Frame Size and Bandwidth: Although you mentioned it's not exceeding the TURN server quota, the frame size seems to impact the number of frames displayed. To optimize:

  1. Further compress your video frames without sacrificing too much quality.
  2. Consider using a lower resolution or frame rate to reduce bandwidth requirements.

WebRTC Configuration: There might be an issue with your WebRTC configuration. To address this:

  1. Review your SDP (Session Description Protocol) configuration.
  2. nsure that your offer and answer SDPs are compatible and include the necessary media codecs.

Browser Limitations: Since you've tested with both Chrome and Firefox, it's less likely to be a browser-specific issue, but it's worth considering:

  1. Test with different browser versions.
  2. Check if there are any known WebRTC issues with the browser versions you're using.

AWS TURN Server Limitations: There might be limitations specific to AWS TURN servers. To investigate:

  1. Review the AWS documentation for any known limitations or quotas related to TURN servers.
  2. Consider testing with a different TURN server to isolate if the issue is specific to AWS TURN servers.

Logging and Debugging: To get more insights into the issue:

  1. Enable detailed logging for your WebRTC application.
  2. Use WebRTC debugging tools to analyze the connection and identify where the stream is failing.

To verify if the problem has been solved:

  1. Implement one or more of the suggested solutions.
  2. Test your video stream with various video lengths and frame rates.
  3. Monitor the number of frames displayed and check if it consistently exceeds the previous limit.
  4. Use browser developer tools to inspect the WebRTC connection and ensure frames are being received continuously.

If the issue persists after trying these solutions, I would recommend contacting AWS Support for more in-depth assistance. They can provide specific guidance based on your account and configuration.

Additional Resources:

Troubleshooting Amazon Kinesis Video Streams with WebRTC - Kinesis Video Streams

Troubleshooting Kinesis Video Streams - Amazon Kinesis Video Streams

Write and examine the code - Amazon Kinesis Video Streams

Hopefully this provides some direction towards the resolution of your issue.

Best wishes and thank you for using AWS!

Brian

AWS
answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.