Live Video Streaming to Server

[Yair Reshef]

On Fri, Apr 17, 2020 at 3:41 PM Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:

> Le jeudi 16 avril 2020 à 16:25 -0500, strange_loop a écrit :
> > hls seems to be not supported in major browsers, however my problem is
> that
>
> See https://github.com/video-dev/hls.js/ it's widely used for the
> purpose. But indeed, HLS is not natively supported in browsers in
> general as it's not part of the standard.
>
> > what is the role of the server is this scenario.
> > Like okey I used  pipeline and video.js but how does my stream reaches
> the
> > client, over internet? How does it distirubuted?
> >
> > I am trying to create a mental model, so that I will know what tool
> serves
> > which purpose.
> >
> > I am very new to streaming, I basically know very little about it.
>
> Streaming capabilities of browser is really poor in fact. That's mostly
> because the browser offers very high level solution where normal OS
> gives you low level UDP socket to play with.
>
> In the case of HLS the flow is the following:
>
> Server:
>   - A server (your RPi) encode and mux into MPEG TS
>   - It then split the MPEG TS in chunk and update a m3u8 playlist
>   - Another server (e.g. nginx) picks these files from disk to make
> them available to your browser
>
> Browser:
>   - The javascript will download though HTTP the m3u8 file and the MPEG
> TS chunk
>   - As MPEG TS is not supported by browser, it will transmux to
> fragmented ISOMP4 (yes, in JavaScript!)
>   - Is passes the chunk to the MSE JavaScript interface
>   - That get decoded and played on screen (using a video tag)
>
> If you use mpegsash, it's a bit lighter, since there is no transmuxing,
> you need a JS library still. For video conferencing it's a bit complex,
> but I'll keep it simple.
>
> You need 2 peers, and web server. Potentially a STUN and/or TURN server
> if the two peers have too restrictive network.
>
>   1. Peers call each other through the web server
>   2. They will use the web server to exchange some info:
>     - Network candidates, for ICE negotiation (nat traversal protocol)
>     - SDP to negotiate the transport and encoding
>   3. When a "connection" is established things goes peer-to-peer
>     - A DTLS connection is established (server no longer see what is
> going on)
>     - RTP and RTCP packets starts flowing
>
> Of course, when you go into big conference, the server becomes your
> peer so that it can do video and audio mixing. In that case, the server
> can see everything that is going on.
>
> In the old days, there was some "video streaming" that was using image
> tags and refreshing it. I think this is still possible using JPEG
> compression.
>

motion delivers such simple robust solution.
brutforce and no audio
but works on anything that can pull a jpeg from a server
https://motion-project.github.io/


>
> >
> >
> >
> >
> > --
> > Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200417/cc43681a/attachment.htm>