Known limitations & Useful commands

[Wkkkkk]

Welcome to this page. We hope this guide enhances your understanding of our streaming program and assists you in resolving any potential issues you might encounter.

[Wkkkkk]

Known Issues and Solutions

While using the program, you might encounter some issues. We have documented these problems and their corresponding solutions below:

1. Ubuntu - Chrome WebRTC Negotiation Issue:

   • Problem: On Ubuntu, playing content using Chrome might lead to a WebRTC negotiation failure, displaying the message "Error resolving 'xxx.local': Name or service not known." This occurs because Chrome mandates the use of anonymized addresses (mDNS hostnames) instead of local IP addresses for WebRTC servers. This measure prevents IP leakage to internet-facing web browsers.
   • Solution: To address mDNS-related issues, consider disabling mDNS in Chrome. To do this, follow these steps:
   1. Open your Chrome browser.
   2. In the address bar, enter chrome://flags and hit Enter.
   3. Search for the setting "mDNS."
   4. Confirm that the setting is marked as "Disabled."
   5. Relaunch Chrome.

2. MacOS - Safari WebRTC Negotiation Issue:

   • Problem: When utilizing Safari on MacOS, you might encounter a WebRTC negotiation failure with the message "Failed to set remote video description send parameters for m-section with mid='video0'." This issue pertains to video codecs and profiles supported by Safari, which has a limited range of codecs it can handle.
   • Solution: For further insights into this issue, refer to this documentation that provides detailed information about video codecs and profiles supported by browsers.

3. Running in Docker on MacOS:

   • Problem: Running the program from a Docker container needs the host-network mode, which is unsupported on Mac systems.
   • Solution: For quick testing, we recommend running the program on an Ubuntu system. Mac users can follow our provided build instructions and employ Chrome for playback. Ubuntu users have the flexibility to build from source or use Docker for testing.

4. Pending WHIP Offer Generation:

   • Issue: At times, the generation of WHIP offers may fail to occur as expected. Viewers would see an error "Pipeline connection failed: No SDP offer from WHIP sink". We are actively working to resolve this issue.

5. Resource Deallocation on Viewer Reload:

   • Problem: Our WebRTC player assumes that viewers will stop playing streams by clicking the stop button before leaving. The allocated resources are released via a DELETE request upon stream completion. However, if a viewer accidentally or intentionally reloads the page without stopping the stream, resources might not be deallocated until the SRT client disconnects (The entire pipeline re-runs upon receiving an end-of-stream (EOS) message).
   • Solution: Ensure that viewers follow the intended workflow of stopping the stream using the provided controls before reloading or leaving the page.

6. Chrome WebRTC Connection Retry:

   • Problem: Chrome will automatically retry a broken WebRTC connection, which could lead to complications when the SRT client (caller) disconnects and then reconnects.
   • Solution: To mitigate potential issues, it's recommended to reload the page when the SRT input stream is changed.

[Wkkkkk]

Useful Commands

1. To generate a testing SRT stream on port 1234 with:

   • FFMpeg

     ffmpeg -f lavfi -re -i testsrc=size=1280x720:rate=30 -f lavfi -re \
     -i sine=frequency=1000:sample_rate=44100 -pix_fmt yuv420p \
     -c:v libx264 -b:v 1000k -g 30 -keyint_min 120 -profile:v baseline -preset veryfast \
     -c:a aac -f mpegts "srt://127.0.0.1:1234?mode=caller&pkt_size=1316"

   • GStreamer

     gst-launch-1.0 -v \
     videotestsrc ! clockoverlay ! video/x-raw, height=360, width=640 ! videoconvert ! x264enc tune=zerolatency ! video/x-h264, profile=constrained-baseline ! mux. \
     audiotestsrc ! audio/x-raw, format=S16LE, channels=2, rate=44100 ! audioconvert ! voaacenc ! aacparse ! mux. \
     mpegtsmux name=mux ! queue ! srtsink uri="srt://127.0.0.1:1234?mode=caller" wait-for-connection=false

   • Our docker image (running in listener mode)

     docker run --rm -p 1234:1234/udp eyevinntechnology/testsrc

   • Note that when SRT stream is in caller mode, the player (listener) needs to run first.

2. To play out an SRT stream on port 1234

   • FFPlay

     ffplay "srt://127.0.0.1:1234?mode=listener"  

   • GStreamer

     gst-launch-1.0 playbin uri="srt://127.0.0.1:1234?mode=listener"

   • VLC

3. File -> Open Network

4. Type in URL: srt://127.0.0.1:1234?mode=listener

• To run as caller, change mode from listener to caller

[birme]

Should all this info perhaps end up in a markdown or the readme.md in the project rather than a GitHub issue?

[Wkkkkk]

Supported Codecs Across Platforms/Broswers

Platform	Broswer	Codecs (profile-level-id)	Supported
Ubuntu	Chrome	AVC Constrained Baseline Level 3.1 (42e01f)	X
Ubuntu	Chrome	AVC Baseline Level 3.1 (42001f)	X
Ubuntu	Chrome	AVC Main Level 3.1 (4d001f)	X
Ubuntu	Chrome	AVC High Level 3.1 (64001f)
Ubuntu	Chrome	AVC High 4:4:4 Predictive Level 3.1 (f4001f)	X
Ubuntu	Chrome	AVC Constrained High Level 3.1 (640c1f)
MacOS	Chrome	AVC Constrained Baseline Level 3.1 (42e01f)	X
MacOS	Chrome	AVC Baseline Level 3.1 (42001f)	X
MacOS	Chrome	AVC Main Level 3.1 (4d001f)	X
MacOS	Chrome	AVC High Level 3.1 (64001f)	X
MacOS	Chrome	AVC High 4:4:4 Predictive Level 3.1 (f4001f)	X
MacOS	Chrome	AVC Constrained High Level 3.1 (640c1f)
MacOS	Safari	AVC Constrained Baseline Level 3.1 (42e01f)	X
MacOS	Safari	AVC Baseline Level 3.1 (42001f)
MacOS	Safari	AVC Main Level 3.1 (4d001f)
MacOS	Safari	AVC High Level 3.1 (64001f)
MacOS	Safari	AVC High 4:4:4 Predictive Level 3.1 (f4001f)
MacOS	Safari	AVC Constrained High Level 3.1 (640c1f)	X