For such streams (which are broken for RTSP and thus for client apps), we could fallback to how it worked previously - so that server's MJPEG stream is a restreaming from camera itself.
When bc-server opens the stream (for motion detection and recordings, it does it anyway), we could make such decision basing on codec (being MJPEG) and pixel format (being yuv422p). The decision in this case is to NOT hand the stream over to RTSP server, we could also make some mark in RTSP server so that it would return some special return code, so that user had a clue what happens, or even bc-client could handle that case by itself by switching to fallback HTTPS-based stream.
For such streams (which are broken for RTSP and thus for client apps), we could fallback to how it worked previously - so that server's MJPEG stream is a restreaming from camera itself. When bc-server opens the stream (for motion detection and recordings, it does it anyway), we could make such decision basing on codec (being MJPEG) and pixel format (being yuv422p). The decision in this case is to NOT hand the stream over to RTSP server, we could also make some mark in RTSP server so that it would return some special return code, so that user had a clue what happens, or even bc-client could handle that case by itself by switching to fallback HTTPS-based stream.