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.
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
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.
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