<p>Although MJPEG may have a more stable and higher temporally local average bitrate, it's bitrate can vary widely given the input content.  See <a href="https://video.stackexchange.com/questions/24915/mjpeg-compression?noredirect=1#comment35435_24915">MJPEG Compression</a>
; the assertion that the resulting network frames/packets will be more consistent is totally unsubstantiated.  It may be, at a macro level, given, say a 10Mb/s Ku Band spotbeam satellite transponder, MJPEG may actually simulate a HARD MUXRATE function that the MPEG Transport Stream muxer typically would perform, but even this is questionable, given MJPEG's highly variable bitrate given very simple content.</p>

<p>Hard Muxrate: <a href="https://stackoverflow.com/questions/44392689/ffmpeg-vbr-cbr-conversion-and-streaming-of-mpeg-2-ts-video-files">https://stackoverflow.com/questions/44392689/ffmpeg-vbr-cbr-conversion-and-streaming-of-mpeg-2-ts-video-files</a></p>

CC BY-SA 4.0
2018-10-09T12:29:56.513Z
2018-10-09T12:29:56.513Z
Andyz Smith
<p>in  <a href="https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/pktvideoaag.html" rel="nofollow noreferrer">https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/pktvideoaag.html</a></p>

<p>it says:</p>

<p>Another type of video compression is MJPEG … the resulting video stream is larger but the packet sizes are more consistent at 1316 bytes (payload)</p>

<p>is that true?</p>

CC BY-SA 4.0
2018-10-02T20:26:14.427Z
Probably. Mjpeg has no inter frame compression. Makes data rates more predictable.
user3643
CC BY-SA 4.0
2018-10-03T14:15:52.473Z
@DigiVisionMedia Ok, does that have anything to do with the packet size?
Andyz Smith
CC BY-SA 4.0
2018-10-03T16:57:28.963Z
I don't know. I'm just speculating. With a compression scheme like mjpeg, each frame is typically very close in size to the ones just before and after it. A smart stream protocol could use this to its advantage.
user3643
CC BY-SA 4.0
2018-10-03T17:08:08.193Z
See [MJPEG wikipedia article](https://en.m.wikipedia.org/wiki/Motion_JPEG). *"HTTP [MJPEG] streaming creates packets of a sequence of JPEG images that can be received by clients."* Supports my speculation. As for verifying that exact packet size number, I can't find anything. Part of the issue is there's no official standard on MJPEG. It's like the great great grandfather of modern web video, born when the web was still wild.
user3643
CC BY-SA 4.0
2018-10-03T21:14:38.057Z
@DigiVisionMedia I guess.  I think each frame is never going to fit in a Ethernet and IP or RTTY or ATM or X.25 or Ku Band QAM satellite packet anyway.  So whether the frames are similar size doesn't have anything to do with the packets.  You're going to fill a bunch of packets, like thousands upon thousands before you get even a full frame.  Whether you fill that last packet to 1299 or 1305 isn't going to make any difference.
Andyz Smith
CC BY-SA 4.0
2018-10-03T21:17:10.163Z
@DigiVisionMedia On a second note, I have seen MJPEG become very variable in Bit rate as well,  it all depends on the complexity of the content.  If you have like a Banner screen like "WORLD TV" and it is all white screen and big black letters, the JPEG quantizer smashes each frames down to like 98 or 200 k.  SO having no intra-frame temporal compress doesn't matter because when you get a frame after the "WORLD TV" frames that is like 400 differnet colors, sixty seventy different silhouetts of animals, people, etc etc you get the idea the bit rate rockets to 1M 2M 3Mbits / sec.
Andyz Smith
CC BY-SA 4.0
2018-10-04T00:27:14.087Z
That's true for all compressions. If the video is very active, it takes more data. But meaningful videos are rarely jumping from static 2 bit colors to 16 bit nature scenes with high movement. At least, not more than a few times here and there. Like I said, I was speculating. I understand mjpeg pretty well. I don't understand networking at all. I could be completely off.
user3643
CC BY-SA 4.0
2018-10-04T00:57:07.820Z
@DigiVisionMedia Well, just keep the basics in mind data transmission over a network always occurs in little chunks, like REAL little, like 1316 **BYTES**.  So even a 320x288 8bit color will be a lot of packets.  This assertion in the CICSO doc seems like someone just mailed it in because there's nothing I can come up with that makes any sense of that.
Andyz Smith
CC BY-SA 4.0
2018-10-04T01:00:35.610Z
@DigiVisionMedia I think maybe if you look at like a LEASED LINE or a SAT TRANSPONDER you know you have a certain link speed and if you don't use it at that speed, well you get charged anyway, so if you end up compressing your H264 video down to 800KB/S it's just stupid because you pay for 10MB/S. So you know MJPEG will get it down to 8MB/s and be basically higher than h264. I'm still not sure about your assertion that the data rate is more predictable.
Andyz Smith
<streaming><compression>
MJPEG Streaming
Andyz Smith
# MJPEG Streaming

(Asked by: username_0 on 2018-09-30)

in <https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Video/pktvideoaag.html>

it says:

Another type of video compression is MJPEG … the resulting video stream is larger but the packet sizes are more consistent at 1316 bytes (payload)

is that true?

**Tags:** streaming, compression

> **Comments:**
> **username_1**: Probably. Mjpeg has no inter frame compression. Makes data rates more predictable.  
> **username_0**: @DigiVisionMedia Ok, does that have anything to do with the packet size?  
> **username_1**: I don't know. I'm just speculating. With a compression scheme like mjpeg, each frame is typically very close in size to the ones just before and after it. A smart stream protocol could use this to its advantage.  
> **username_1**: See [MJPEG wikipedia article](https://en.m.wikipedia.org/wiki/Motion_JPEG). *"HTTP [MJPEG] streaming creates packets of a sequence of JPEG images that can be received by clients."* Supports my speculation. As for verifying that exact packet size number, I can't find anything. Part of the issue is there's no official standard on MJPEG. It's like the great great grandfather of modern web video, born when the web was still wild.  
> **username_0**: @DigiVisionMedia I guess.  I think each frame is never going to fit in a Ethernet and IP or RTTY or ATM or X.25 or Ku Band QAM satellite packet anyway.  So whether the frames are similar size doesn't have anything to do with the packets.  You're going to fill a bunch of packets, like thousands upon thousands before you get even a full frame.  Whether you fill that last packet to 1299 or 1305 isn't going to make any difference.  
> **username_0**: @DigiVisionMedia On a second note, I have seen MJPEG become very variable in Bit rate as well,  it all depends on the complexity of the content.  If you have like a Banner screen like "WORLD TV" and it is all white screen and big black letters, the JPEG quantizer smashes each frames down to like 98 or 200 k.  SO having no intra-frame temporal compress doesn't matter because when you get a frame after the "WORLD TV" frames that is like 400 differnet colors, sixty seventy different silhouetts of animals, people, etc etc you get the idea the bit rate rockets to 1M 2M 3Mbits / sec.  
> **username_1**: That's true for all compressions. If the video is very active, it takes more data. But meaningful videos are rarely jumping from static 2 bit colors to 16 bit nature scenes with high movement. At least, not more than a few times here and there. Like I said, I was speculating. I understand mjpeg pretty well. I don't understand networking at all. I could be completely off.  
> **username_0**: @DigiVisionMedia Well, just keep the basics in mind data transmission over a network always occurs in little chunks, like REAL little, like 1316 **BYTES**.  So even a 320x288 8bit color will be a lot of packets.  This assertion in the CICSO doc seems like someone just mailed it in because there's nothing I can come up with that makes any sense of that.  
> **username_0**: @DigiVisionMedia I think maybe if you look at like a LEASED LINE or a SAT TRANSPONDER you know you have a certain link speed and if you don't use it at that speed, well you get charged anyway, so if you end up compressing your H264 video down to 800KB/S it's just stupid because you pay for 10MB/S. So you know MJPEG will get it down to 8MB/s and be basically higher than h264. I'm still not sure about your assertion that the data rate is more predictable.  

---

## 1 answers

### Answer by username_0 on 2018-10-09. Score: 0 | Accepted answer

Although MJPEG may have a more stable and higher temporally local average bitrate, it's bitrate can vary widely given the input content. See [MJPEG Compression](https://video.stackexchange.com/questions/24915/mjpeg-compression?noredirect=1#comment35435_24915)
; the assertion that the resulting network frames/packets will be more consistent is totally unsubstantiated. It may be, at a macro level, given, say a 10Mb/s Ku Band spotbeam satellite transponder, MJPEG may actually simulate a HARD MUXRATE function that the MPEG Transport Stream muxer typically would perform, but even this is questionable, given MJPEG's highly variable bitrate given very simple content.

Hard Muxrate: <https://stackoverflow.com/questions/44392689/ffmpeg-vbr-cbr-conversion-and-streaming-of-mpeg-2-ts-video-files>


---

