@wb666greene: Yes that is indeed when the websocket is loaded to high. Dashboard won't be responsive anymore. That is why I wanted (in my node-red-contrib-ui-camera node) to have two modes:
- Push the messages to the dashboard, since that is fairly easy for users (just send a message with an image to the node's input). But I will warn them that this is not advised for lots of data.
- Pull the messages from the node-red flow (by using a 'src' attribute). A bit more work to setup, but much better performance.
@happytm. WebRtc is indeed also an option. But perhaps somebody can later on make a dedicated UI node for webrtc. And as @wb666greene responded to your post, I also 'think' we cannot use it here for decoding a stream into individual images (like rtsp).
@dceejay: in that case you are aiming at the node-red-contrib-ui-media? In the first version of my node-red-contrib-ui-camera node, I also had stuff provided to show images and video files. But I removed it from my node, since camera content has no finite length (like an image or video file). And I want to have PTZ controls, zones (with polygons), ... Not sure if it is wise to put all together in a single node, just because they both show an image (sequence)? To me camera images belong in a dedicated node...
The word "absolutely" sounds as music in my ears. This means that all experiments above have at least resulted in something usable. 
But indeed like you say: by having solved the rtsp stream decoding, we will end up with a massive amount of images in Node-RED. New developments will be required to be able to handle all this data. But one step at a time ... We have already done a lot of experiments with OpenCv matrices in Node-RED, but we had lots of issues when messages (containing references to OpenCv matrices) are cloned by Node-RED, and when NodeJS starts its garbage collection of those messages. But I have no time at the moment to digg into that again ...
