HUB5: Video streaming RabbitMQ Pipeline; ABR Algs, Networking Protocols, post-processing queue, metrics+analytics #386
Description
HUB5: An Epic for scalable and efficient realtime streaming through RabbitMQ pipeline
Seamless live video streaming with optimized networking, empirical/case specific algorithms, efficient adaptative encoding and optimized hardware utilization, while keeping low-coupled and distributed rabbitmq infrastructure benefits.
Research and references
Wiki dedicated to this: https://github.com/leobrod44/Smartess/wiki/Research-notes
Description and Main Tasks
See the several stories and substories descriptions
RabbitMQ Streams Datastructure and efficient networking
- Partitionned Append-only persistent message which would allow replays of video segments
- Out of order user clients or clients with different resources; view video stream at own pace
- Fault tolerance and buffering: Reliable to view lost frames/segments still in TTL
- Log-like data structure which allow analytics
- Eventual Consistency RabbitMQ design
- Fault tolerant; packet loss and retransmission, FEC, SVC, buffering strategy
- Better than queue if many users for same hub;
- cluster utilization, load balancing across server and clients
- Persistence or replication is efficient for any users while message are still in TTL
- High throughput, low latency .. over queues
- HLS Playlists and fast Codecs integration;
- ABR algs could be both/either on frontend JS or go consumer; flexibility
- SVC: best encoding stored in MQ Stream, if needed later on worst network, can always compress down
Misc
Keywords: ABR algorithms, latency, buffering, compression schemes, ffmpeg, omnvif, message encoding, AMQP, RTC, WebRTC, WebSocket, BufferedReader, segmenting vs sequencing, HLS,RTSP, RTMP, Shovel Plugin, Go2RTC, QoS, IoT, Latency, Buffering strategies, Volatility, MQ regions, LAN priority channels, segments/frame loss management
Extract from meeting minutes mentioning complexity of video stream feature when first introduced in meetings