3 ms·

As mentioned in a different comment - mjpeg is certainly less bandwidth efficient, but it's super simple to implement - just the Python code I've posted plus an

As mentioned in a different comment - mjpeg is certainly less bandwidth efficient, but it's super simple to implement - just the Python code I've posted plus an image tag. Also, streaming protocols tend to have a number of seconds latency, which for certain types of applications isn't acceptable. That's when mjpeg might do the job because it just instantly starts blasting frames down the tubes.

monocasa 5y ago
> Also, streaming protocols tend to have a number of seconds latency, which for certain types of applications isn't acceptable. That's when mjpeg might do the job because it just instantly starts blasting frames down the tubes. In this case you might run into issues there. This demo is all on TCP which means head of line blocking. That's why you typically see MJPEG wrapped in rtp rather than http.
bawolff 5y ago
I agree that mjpeg is super simple and streaming support can get complicated very fast. There a certainly use cases where mjpeg is the correct trade off. But don't under estimate bandwidth scaling requirements - i think if you have 20 clients streaming 1080p@24 fps, you're already maxing out a 1 gbps line. Even still though, latency can't be that bad for video formats with actual temporal compression in low latency mode. I'm not an expert in this area, but WebRTC is widely supported, uses vp9. When i do video conferencing with people the latency is pretty low, so this must be a solved problem.
vlovich123 5y ago
I’ll have to disagree with you there. Oculus Link uses a (HW) h264 encoder and run at pretty high resolutions without multiple seconds of latency. Latency is in the network layer mostly (and maybe improper tuning of codecs) and that’s helped more by sending smaller data, not larger. Maybe if you don’t have HW acceleration, but that’s rare as even CPUs have Hw encoding blocks (Intel’s QuickSync for example).

monocasa 5y ago

> Also, streaming protocols tend to have a number of seconds latency, which for certain types of applications isn't acceptable. That's when mjpeg might do the job because it just instantly starts blasting frames down the tubes. In this case you might run into issues there. This demo is all on TCP which means head of line blocking. That's why you typically see MJPEG wrapped in rtp rather than http.

bawolff 5y ago

I agree that mjpeg is super simple and streaming support can get complicated very fast. There a certainly use cases where mjpeg is the correct trade off. But don't under estimate bandwidth scaling requirements - i think if you have 20 clients streaming 1080p@24 fps, you're already maxing out a 1 gbps line. Even still though, latency can't be that bad for video formats with actual temporal compression in low latency mode. I'm not an expert in this area, but WebRTC is widely supported, uses vp9. When i do video conferencing with people the latency is pretty low, so this must be a solved problem.

vlovich123 5y ago

I’ll have to disagree with you there. Oculus Link uses a (HW) h264 encoder and run at pretty high resolutions without multiple seconds of latency. Latency is in the network layer mostly (and maybe improper tuning of codecs) and that’s helped more by sending smaller data, not larger. Maybe if you don’t have HW acceleration, but that’s rare as even CPUs have Hw encoding blocks (Intel’s QuickSync for example).