Troubleshooting Concurrent Video Stream Access at multiple locations simultaneously without encountering errors

General Discussion
1

Hi All,

Github - http-launch/src at master · sdroege/http-launch · GitHub

I attempted to launch the server from the GitHub location via HTTP, and it functioned correctly upon initial loading. However, upon attempting to open it in another webpage or VLC player, the streaming did not commence properly. I have included the error message below. Could you please assist me in accessing the video stream at multiple locations simultaneously without encountering errors?

Errors:

./http-launch 8080 v4l2src device=“/dev/video0” ! videoconvert ! queue ! x264enc tune=zerolatency ! h264parse config-interval=-1 ! mp4mux fragment-duration=10 name=stream
Listening on http://192.168.100.5:8080/
New connection 192.168.100.5:45080
Starting to stream to 192.168.100.5:45080
Starting pipeline
New connection 192.168.100.5:45082 // Second try to load the IP address
Starting to stream to 192.168.100.5:45082
Removing connection 192.168.100.5:45082 // Immediately connection removed

Regards,
Sulthan

2

Any update regarding above issue?

3

Hi all,

Any update above mentioned issue?

4

I don’t have an answer to your question, but just a note that the latest version of this code is now at subprojects/gst-examples/network/http-launch/http-launch.c · main · GStreamer / gstreamer · GitLab (I don’t think much has changed though, if anything at all).

5

Yes @tpm ,

I had checked, changes related to print statement only, still my issue not resolved :disappointed:, can you please help , how to resolve the multiple connection issue?

Regards,
Sulthan

6

The problem is that when the second client connects it only receives the mp4 moof fragments as they are being generated, but it does not receive the initial mp4 moov fragment with the stream headers. Because of that, the second client doesn’t know how to interpret the data in the moof fragments that are being sent.

The reason for that is that mp4mux does not seem to put a streamheader field in the output caps.

It works fine with the isofmp4mux element from the gst-plugins-rs module though, also with much lower latency:

$ ./http-launch 7070 v4l2src ! videoconvert ! queue ! x264enc tune=zerolatency ! h264parse config-interval=-1 ! isofmp4mux fragment-duration=10 name=stream
7

Hi @tpm,

Thank you for your response.

I’ve encountered a similar issue with gstreamear version 1.14. I attempted to install the gstreamer-rs package but encountered difficulties. Furthermore, my platform board (QCS610) is unable to accommodate an upgrade to the gstreamer version. I’m seeking a solution that would allow me to work with the existing version 1.14. Do you know of any possible resolutions for this issue?

Thanks,
Sulthan

8

In principle it should be possible to build gst-plugins-rs against GStreamer 1.14, but the mux/fmp4 plugin seems to require GStreamer 1.18 from the look of it, sorry.

9

Hi @tpm ,

Thank you for your response.

In your message, you mentioned:

“The problem is that when the second client connects it only receives the mp4 moof fragments as they are being generated, but it does not receive the initial mp4 moov fragment with the stream headers.”

I have checked multiple references and found a sample application that seems to be working fine with multiple connections in VLC. Can you please refer to the below reference sample application and confirm if anything is missing in your application?

Sample Application Link

If you need further assistance or clarification, feel free to let me know.

10

I’m not sure sure what you’re looking for here.

That sample application uses oggmux which doesn’t have the problem I mentioned that mp4mux has.