MPEGTS would be great for things I have wanted to do in the past, and all you probably have to do is hack the video element so it can handle that.
I think the thing about MJPEG and webcams is that it's relatively easy to make MJPEG from a webcam. MPEGTS would require more code I think?
So (i) if you want a solution that works out of box on any device, (ii) if you have enough bandwidth and (iii) if you are not interested in video quality, Mjpeg over Http is a good trade-off.
I was using ffserver also.
I don't particularly need the HTTP layer nor the browser itself. But I can tell a colleague on the office network: Look at my $WEBCAM_URL to show them something on my STB so that's nice. If I could say "ffplay $WEBCAM_PARAMS_AND_IP_ADDRESS" and it was available within the office, that would be the same.
Therefore no audio and compression/quality is shit. Also, MJPEG stream doesn't have timestamps, so it's impossible to provide smooth playback of MJPEG stream, or synchronize it with other streams.
We do need a video transport better than MJPEG, but please don't make it RTP-based
Just use VLC, as everybody else.
BTW what is so complex in RTP?
Please don't. TCP is entirely inadequate for streaming because of head-of-line blocking behavior. Nobody use RFC4571 for that very reason.
You can make TCP/HTTP work for streaming, but that usually involves developing some fragile system that does chunking, buffering, and retries. Probably implemented as a sizeable pile of custom idiosyncratic Ajax.
Granted this project looks like a lot more streamlined.
