implement video streaming services systematically, both low-latency and compressed

[nettings]

Right now, we have an ad-hoc HDMI over IP streamer (which is pretty cool). What we want instead is more of a generic framework:

• take signals from MJPEG sources such as a HDMI grabber or simple webcam, and forward them uncompressed, with minimal latency, either uni- or multicasted

• take signals from H264 sources or files, or compress MJPEG sources on-the-fly on the hardware, and forward them as a H264 stream, with slightly higher but still minimal latency, either uni- or multicasted

• receive MJPEG signals and play them back on either HDMI output

• receive H264 streams and play them back on either HDMI output

• later: both of the latter, but as part of a multiviewer setup, i.e. in a smaller window at a configurable position.

Eventually, it would be nice to configure one service that automatically handles video via gstreamer and audio via zita-njbridge with only a single IP configuration. IGMP snooping works via multicast groups, so it's ok to reuse one if two streams are related. This only becomes wasteful if hosts want to listen without watching. If we want to avoid this, define a numbering scheme (even-numbered IPs: video, odd-numbered ones: audio, port 29998: h264 video, port 29999: MJPEG video, port 30000: zita-njbridge audio, all UDP).

[nettings]

Also, consider implementing the hostname lookup more widely, as exemplified in mn_hdmi-tx - the same approach would be useful to zita-njbridge services.