Deliver video frames over WebSocket when JS is allowed

[ethanjli]

Refer to:

• https://www.mux.com/blog/the-state-of-going-live-from-a-browser
• https://ably.com/topic/websockets-golang
• https://www.reddit.com/r/golang/comments/bjoc7l/video_livestreaming_with_go/
• https://github.com/timdrysdale/vw

We can send msgpack blobs of frames (including annotation data/metadata) over a dedicated Action Cable connection. Refer to:

• https://guides.rubyonrails.org/action_cable_overview.html

We should use a separate WebSocket connection for the underlying transport of the Action Cable connection because WebSocket is susceptible to head-of-line blocking (refer to https://hpbn.co/websocket/ ). So for example we'd have /cable for normal Action Cable channels, and then /video-cable for the video delivery Action Cable channels.

Probably the simplest approach is to deliver JPEG frames (along with all metadata) over an Action Cable connection, allowing flow control/feedback to be associated with the Action Cable channels used for video frame delivery. Then we'd put frames in a video player component or custom element (e.g. a canvas).

If we don't send the JPEG frames over Turbo Streams, maybe the stream player can be a custom HTML element which also displays accompanying timestamps and (optionally) metrics about dropped frames at ingress from the source and egress to the current browser. Refer to:

• https://www.youtube.com/watch?v=qMcNDWyRw20
• https://www.youtube.com/watch?v=ckJm22pCP8g
• https://github.com/muxinc/media-chrome
• https://www.mux.com/blog/canvas-adding-filters-and-more-to-video-using-just-a-browser
• https://youtu.be/OBhlTcllq_E
  Then we could also build up a buffer for smoother playback for users who are not performing real-time control (e.g. not designated as pump operators).

Tasks:

• Make a canvas-based custom element which simply displays frames received over Action Cable (Use Action Cable with MessagePack encoding to deliver video stream frames #153)
• Try out having one WebSocket connection per video stream, using Action Cable for CSRF and channel integrity (Use Action Cable with MessagePack encoding to deliver video stream frames #153)
• Deliver video frames with metadata using the actioncable-v1-msgpack subprotocol and the Any Cable client (Use Action Cable with MessagePack encoding to deliver video stream frames #153)
• If we must multiplex using Action Cable, improve fairness of the scheduling of video-cable utilization, to prevent any one stream from being starved - maybe with round-robin reading from each send channel for a given action cable connection? Not needed - having one WebSocket connection per connection works and is simpler, and it's more like the MJPEG-over-HTTP approach for no-JS browsers.
• Confirm whether this works in iOS Safari with JS enabled (embedded MJPEG streams don't seem to work there)
• Add toggle for showing frame timestamp in the stream player
• Add a local buffer of most-recently-received frames in the stream player, with scrubbing