6 ms·

Motion JPEG isnt resilient. H264/H265/VP9, etc all build on some of the ideas that JPEG introduces, but introduce features that allow for the stream to be resil

Motion JPEG isnt resilient. H264/H265/VP9, etc all build on some of the ideas that JPEG introduces, but introduce features that allow for the stream to be resilient to dropped packets or frames. Its a cool idea, it just doesn't work in practice. Especially since a lot of these video standards are transmitted over UDP.

Ono-Sendai 11y ago
Interesting. I would have thought it would be reasonably resilient though, due to its intra-frame nature. If you get lost in the stream you could scan forward to the next JPEG header.
- fndrplayer13 11y ago
  Thats true in a sense, actually. The thing is with H264/H265/VP9, etc dropped packets or missing data is somewhat acceptable as long as you have a key frame. You just end up with interpolated or 'guess' data (aka the droopy or ice-cream frame effects). With Motion JPEG the frame typically just freezes until another good frame is retrieved and decoded. Motion JPEG isn't a standard though, really, so perhaps what I've seen doesn't match others experiences. mJPEG is cool though for stuff on your local network or other places where you know you'll have a reliable dedicated network. If you have a nice wifi or wired network too you can crank up the quality on an mjpeg stream and get some really gorgeous quality streaming video, as long as the receiving devices can effectively buffer all that network data :)
- pedrocr 11y ago
  Depends on what you mean by MJPEG, it's not really standardized anywhere. I'm aware of at least two meanings: 1) Take a stream of images calculate images that are the differences between subsequent frames and then JPEG encode the first image and the subsequent differences. The decoder then does the opposite. Once you lose a frame you're done so its better to actually encode a full frame once in a while (do I and B frames like normal codecs). 2) Just push a set of full JPEG images as individual frames. This is the most common usage of MJPEG these days as it's what you get from IP surveillance cameras and stuff like that. This is actually reasonably standardized as it's basically HTTP multipart where each of the parts is just a new jpeg. If you point an HTML img tag to a HTTP GET endpoint like that most browsers will display a video stream.

Ono-Sendai 11y ago

Interesting. I would have thought it would be reasonably resilient though, due to its intra-frame nature. If you get lost in the stream you could scan forward to the next JPEG header.

fndrplayer13 11y ago
Thats true in a sense, actually. The thing is with H264/H265/VP9, etc dropped packets or missing data is somewhat acceptable as long as you have a key frame. You just end up with interpolated or 'guess' data (aka the droopy or ice-cream frame effects). With Motion JPEG the frame typically just freezes until another good frame is retrieved and decoded. Motion JPEG isn't a standard though, really, so perhaps what I've seen doesn't match others experiences. mJPEG is cool though for stuff on your local network or other places where you know you'll have a reliable dedicated network. If you have a nice wifi or wired network too you can crank up the quality on an mjpeg stream and get some really gorgeous quality streaming video, as long as the receiving devices can effectively buffer all that network data :)
pedrocr 11y ago
Depends on what you mean by MJPEG, it's not really standardized anywhere. I'm aware of at least two meanings: 1) Take a stream of images calculate images that are the differences between subsequent frames and then JPEG encode the first image and the subsequent differences. The decoder then does the opposite. Once you lose a frame you're done so its better to actually encode a full frame once in a while (do I and B frames like normal codecs). 2) Just push a set of full JPEG images as individual frames. This is the most common usage of MJPEG these days as it's what you get from IP surveillance cameras and stuff like that. This is actually reasonably standardized as it's basically HTTP multipart where each of the parts is just a new jpeg. If you point an HTML img tag to a HTTP GET endpoint like that most browsers will display a video stream.