1. Broadcasters start live streams on their devices (phone/laptop/dedicated digital video recording device).
2. The broadcasting device sends a UDP/RTSP/RTMP streams to a thin MQTT Broker specific proxy.
3. The proxy resides within both the Broadcaster’s and the Viewer’s infrastructure.
4. In the Stream Ingestion Phase, the proxy encapsulates the stream payload into MQTT or broker specific message format and forwards to the broker.
5. In the Stream Distribution Phase, the broker must ensure that the stream is delivered (fan out) to the viewing device’s proxy.
6. In the Request Load-balancing Phase, the Viewers register viewing requests with care-of receiving proxies and these proxies then decapsulates SMF into the original streaming transport format (UDP/RTSP/RTMP) and forwards the stream to its care-of viewer. If the viewer is able to receive the stream in other protocol such as MQTT/HTTP, then the message broker can deliver directly to the Viewer bypassing the receiving proxy as well.
Since the MQTT Broker move data base on topics, a Broadcaster can ingest its live video stream to a topic, e.g. channel/id_1, and any stream viewer subscribes to topic channel/id_1 will receive the live stream.
Likewise, a transcoder can monitor if there are any channel/id_1/# subscriptions, and if so, it can then subscribe to channel/id_1, take the stream and transcode it to a specific format and re-ingest back to the Messaging Broker with a topic of, say, channel/id_1/h264/320×160/50kbps. Any stream viewer that subscribes to topic channel/id_1/h264/320×160/50kbps will receive live video stream on channel 1 with h264 encoding at the resolution of 320×160 and bit rate of 50kbps.
You need to keep bandwidth utilisation and scalability in view though when architecting a video streaming/chat application. A hardware form factor helps.
Thanks and Regards,
Sumeet.