How to organize h264 playback in the browser with minimal delay?

Question

Video broadcast

I'm trying to organize a video broadcast from the camera to the browser, the client is always the same. As a result, you need to get a delay close to zero and cross-browser compatibility is very desirable, at least support for desktop Chrome + Firefox + Opera + Safari (as the need decreases) half a year old. Of the pluses - cross-browser compatibility, simplicity in terms of coding, most users already have it installed. And another great plus is the ability to broadcast via UDP (change RTMP to RTMFP), which will reduce delays in packet transmission. BUT! It was not possible to achieve a delay of less than 8 frames, it was perverted in various ways, the buffering was twisted to zero, but to no avail. In fact, the flush seems to continue buffering anyway. There may be some low-level settings for the flash decoder, but I did not find them = (. 2) HTML5
For the test, I organized an RTMP server on nginx, transferring video (720x1280 30fps) to it with Gstreamer. Further, in order to measure the minimum possible delay, I arranged the playback of the rtmp stream again through gstreamer. the result is a delay of 2-3 frames. Further I try to achieve the same, but through the browser:
1) Flash.
It seems that all top browsers already understand html5-video encoded in h264. But the minimum delay (buffers by zeros) is about 14 frames. The delay depends on the browser. UDP - nizya=(
3) Java applet - like a crutch (I use it now), with gstreamer-java . The delay is ideal - the same 2-3 frames as with simple playback through gstreamer, which is actually not strange. You can broadcast via UDP. lame multiplatform, because for each OS and architecture you need to load your libraries gstreamer and gstreamer-java
4) VLC browser plugin. It has not yet been fully tested, but it has already been possible to achieve a delay of 5 frames. Cons - requires installation, works only in Firefox.
Ideally - to combine the advantages of gstreamer-java and flash ... It would be delicious!
Perhaps someone managed to achieve instant translation into the browser? Please help!

Answer 1

The client is always the same, the traffic source is known in advance. Conclusion - why fence the garden from gstreamer, rtmp ... Serve from the console via ffmpeg in the rtsp transport. In the browser, you can accept the same flow-player. But all this will still be with at least some, but buffering. For an ideal transmission, the delay of which will be slightly more than the network, you need to use telephone protocols, with separate signaling. You can dig deeper with SIP .
You say that delays should be minimized. This is usually required for video conferencing. And you, I believe, understand that all sorts of ciscos, eriksons and other polycoms spend money on developing their proprietary protocols for this purpose. If everything was so accessible, they probably wouldn't do it.