Hello,
I'm still fairly new to GStreamer. I'd like to be able to use GStreamer to send 'live' webcam stream over the Internet using HTTP. It seems, the 'Soup' element is used to accomplish this...and it can be either a 'sink' (server) or a 'source' (client)... I have some confusion on who is the 'sender' and 'receiver' in this case? I was under the impression the 'sender' (the one creating/streaming the webcam feed) would be considered the 'server' (and thus the pipeline on that machine would use the 'Soupsink')...while the receiving machine (located at the IP address/port used by the sender) would use the 'Soupsrc'. Since the 'Soup' element seems to require those 2 pipelines (1 for sender and 1 for receiver) how is the 'receiver' pipeline code sent to that remote receiving machine...? Is a separate FTP transfer or similar process used to send an 'information' file to the remote machine (with GStreamer installed and running as well)...? Is it not possible for the 'sender' to run the appropriate pipeline on their local machine to enable their own IP address to be accessed over the Internet by remote browsers...? In this way both pipelines would be run on that same 'broadcaster' machine...? Also in that way any remote browser should (in theory) be able to access/view that live stream if the sender's IP address is known. Also since HTTP uses port 80...how is it possible for the sender's stream to be viewed by multiple remote browsers...instead of only 1...is there a need to assign different ports for multiple stream views? I apologize in advance if these are stupid questions...just trying to 'get my head around' the general process required to accomplish this using GStreamer...thanks in advance for any advice. Regards -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Administrator
|
You can sondier using WebRTC or Websocket for such a workflow.
If delay is not your concern, you can consider fragmenting the content separately using hlssink, and then host the fragments using a separate Web server like Apache ~BO -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Greetings,
Thank you for your reply. Yes I thought of RTP however assumed a private web server would be necessary...as your answer seems to indicate. Also the speed would need to be as fast as possible...delay from origin to destination not so much of a concern...if that is what you are referring to when you mention the 'delay'. Thanks again. Regards -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Administrator
|
The 'delay' refers to the stream delay in case of HLS and not delivery delay
due to network latency! HLS or any other ABR formats for that matter will have one fragment worth of latency, since a client fully needs to download the fragment and then start playing. Hence, even at origin, you would have to live with 1 fragment worth of latency ~BO -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |