视频编解码类型MJPEG数据格式介绍 update:2021-9-30 Motion JPEG(M-JPEG或MJPEG，Motion
Joint Photographic Experts
Group，FourCC:MJPG)是一种影像压缩格式，其中每一帧图像都分别使用JPEG编码。M-JPEG常用在数字相机和摄像头之类的图像采集设备上。MJPEG即动态JPEG，按照至少达到25帧/秒速度使用JPEG压缩算法压缩视频信号，完成动态视频的压缩。MJPEG压缩标准是由JPEG专家组制定的，其图像格式是对每一帧JPEG图像进行压缩。MJPEG是一种基于静态图像压缩技术JPEG发展起来的动态图像压缩技术，可以生成序列化的运动图像。实际上MJPEG图像数据流就是一帧一帧的JPEG格式图片。

MJPEG只是有帧内压缩(区别于算法更复杂的帧间压缩)，只单独的对某一帧进行压缩，而不考虑影像画面中不同帧之间的变化。因此压缩效率比较低，而使用了帧间压缩的现代影像压缩格式(如MPEG1、MPEG2和H.264/MPEG-4
AVC)一般压缩率比较高。

MJPEG是一种基于静态图像JPEG压缩标准的动态图像压缩标准，压缩过程是将视频序列的每一帧视为一幅静止图像进行压缩。因此，要进行MJPEG压缩，首先必须实现静态图像的JPEG压缩。JPEG定义了两种基本的算法：基于DCT的有失真压缩算法和基于DPCM的无失真压缩算法。基于DCT的有失真JPEG压缩算法主要分为5个基本步骤：色彩空间变换及采样、离散余弦变换DCT、量化、Z字形编排、编码。

JPEG是一种很灵活的格式，具有调节图像质量的功能，允许用不同的压缩比例对文件进行压缩，支持多种压缩级别。压缩比越大，品质就越低。

JPEG委员会在制定JPEG标准时，定义了许多标记码(marker)或标记段(marker
segments)组成，用来区分和识别图像数据及其相关信息。目前，使用比较广泛的是其交换格式JFIF(Jpeg File
Interchange
Format)。JPEG的每个标记码都是由2个字节组成，其前一个字节是固定值0xFF，每个标记码之前还可以添加数目不限的0xFF填充字节。JPEG文件中的字节是按照正序排列的，即高位字节在前，低位字节在后。

JFIF即JPEG文件交换格式(JPEG File Interchange Format,
JFIF)是一个图像文件格式标准。它是一种交换符合JPEG交换格式(JIF)标准的JPEG编码文件的格式。它解决了JIF在简单JPEG编码文件交换方面的一些限制。与所有符号JIF的文件一样，JFIF文件中的图像数据使用JPEG标准的技术压缩，因此JFIF有时被称为”JPEG/JFIF”。在JFIF中，图像样本的存放顺序是从左到右和从上到下。

按照JFIF，JPEG文件由两个部分组成：文件头部分和图像压缩数据。其中文件头部分分为一个一个的段来存储(但并不是全部都是段)，段的多少和长度并不确定。只要包含了足够的信息，该JPEG文件就能够被打开。文件头部分的每个段都一定包含两部分，一个是段的标记码，它由两个字节构成：第一个字节是十六进制0xFF,第二个字节对于不同的段，有不同的值。紧接着的两个字节存放的是这个段的长度。这个长度的表示方法是按照高位在前，低位在后。另外，为了避免文件头部分和图像压缩数据部分的冲突，在对图像数据进行huffman编码时如果产生了一个0xFF，那么就用0xFF
0x00代替。因此在对压缩数据部分进行解码时，如果一个0xFF的后面字节不是0x00，那么这个字节没有意义，如果0xFF后一字节为0x00，则将此两个字节作为一个字节0xFF进行处理。由于文件头中包含了解码图像时必须的量化表、Huffman表、图像格式等信息，因此输出的第一帧JPEG数据流必须包含文件头。由于接下来编码的图像都是按照相同的方式进行编码的，因此可以不包含文件头，只需要在编码结束时产生一个表示编码结束的标记，用于区分不同帧图像，解码时在图像头部添加上文件头，将编码图像转变为标准的JPEG图像即可。

Referenced from:https://www.pianshen.com/article/8348772319/

Motion JPEG（M-JPEG或MJPEG，Motion Joint Photographic Experts Group，FourCC:MJPG）是一种影像压缩格式，其中每一帧图像都分别使用JPEG编码。M-JPEG常用在数字相机和摄像头之类的图像采集设备上，非线性剪辑系统也常用这种格式。QuickTime播放器和包括Mozilla Firefox，Google Chrome，Safari在内许多网页浏览器原生支持M-JPEG。
M-JPEG被广泛应用在网页浏览器，媒体播放器，数字相机，摄像头，流媒体服务器和非线性剪辑系统中。

RTSP摄像机为什么还保留MJPEG编码格式 update:2021-9-30 MJPEG编码有以下特点：

MJPEG(MotionJPEG)是以JPEG技术为基础扩展研发出来的动态图像压缩技术，不过它通常只单独的对某一帧进行压缩，基本不会考虑视频流中不同帧之间的变化，优点如下：

1、通过此压缩技术可获取清晰度很高的视频图像，可灵活设置每路的视频清晰度和压缩帧数。

2、压缩后的画面还可任意剪接。

为什么在网络摄像机的应用中,MJPEG还占有一席之地呢?

MJPEG实现成本最低，市场上先进的技术和成熟的技术并存。MJPEG获得较好的单幅图像质量，能够精确到帧的编辑，有利于编辑，受网络丢包问题影响较小，所以在众多中低产品中仍有应用。

目前来看，H.264/H.265相对比MJPEG的视频编码算法的效果更好，并且也更适合网络视频数据的传输，所以，在选择网络摄像机、网络视频编码器等产品时，首选也是H.264/H.265视频编码标准，如果需要对视频帧进行分析或编辑只用，可以配置RTSP
MJPEG编码，通过播放端拉流，回调相关数据，实现快速视频编辑或识别处理目的。

Referenced from:https://blog.csdn.net/weixin_33873846/article/details/89545442

RTP/JPEG Packet Format

The RTP timestamp is in units of 90000Hz. The same timestamp MUST
appear in each fragment of a given frame. The RTP marker bit MUST be
set in the last packet of a frame.

JPEG header

Each packet contains a special JPEG header which immediately follows
the RTP header. The first 8 bytes of this header, called the "main
JPEG header", are as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type-specific |              Fragment Offset                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |       Q       |     Width     |     Height    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Width: 8 bits

This field encodes the width of the image in 8-pixel multiples (e.g.,
a width of 40 denotes an image 320 pixels wide). The maximum width
is 2040 pixels.

RFC 2435 RTP Payload Format for JPEG October 1998

Height: 8 bits

This field encodes the height of the image in 8-pixel multiples
(e.g., a height of 30 denotes an image 240 pixels tall). When
encoding interlaced video, this is the height of a video field, since
fields are individually JPEG encoded. The maximum height is 2040
pixels.

来自：https://datatracker.ietf.org/doc/html/rfc2435

主要限制就是长宽最大2040像素（255*8)

在so上，就有人遇到过这个问题。

ffmpeg - MJPEG streaming over RTSP - Stack Overflow update:2021-9-30
I am capturing JPEG images from an IP-camera over RTSP. I use live555

• libavcodec for streaming and decoding the MJPEG image. The stream works fine up to the image resolution 2048 x 1920. But when I increase

1. image width above 2048, I get a bar-shaped rectangular image of

very small width (i.e., 544x1920). The image is correctly captured and
saved on the camera. The problem occurs only when I stream the image
over RTSP to the PC. Is there any payload restriction in RTP for
high-resolution MJPEG?

Referenced from:https://stackoverflow.com/questions/7639054/mjpeg-streaming-over-rtsp

ffmpeg - 通过RTSP传输MJPEG 我正在通过RTSP从IP摄像机捕获JPEG图像。我使用live555 +
libavcodec进行流传输和解码MJPEG图像。该流在高达2048 x
1920的图像分辨率下可以正常工作。但是，当我将图像宽度增加到2048以上时，会得到宽度非常小的条形矩形图像（即544x1920）。图像已正确捕获并保存在相机上。仅当我通过RTSP将图像流式传输到PC时，才会出现此问题。
RTP中对高分辨率MJPEG有有效载荷限制吗？

最佳答案

请阅读第4页底部的http://tools.ietf.org/html/rfc2435。在这里，图像的最大宽度为2040。使用ONVIF标准可以解决此问题。

Referenced from:https://www.coder.work/article/6445074

JPEG over RTP when resolution larger then 2040*2040

參考 rfc2435，當使用 RTP 傳送封包時，此處定義的長寬最大值為2040。那麼當超過 2040 時，應該如何實作呢?? 以下提供幾種作法當作參考。

一、參考 rfc5371，使用 JPEG2000 的作法
作法是在 SDP 內加以描述，範例如下：
m=video 49170/2 RTP/AVP 98
a=rtpmap:98 jpeg2000/90000
a=fmtp:98 sampling=YCbCr-4:2:0;width=128;height=128

二、參考 ONVIF-Streaming-Spec-v221.pdf 定義的 JPEG over RTP
作法是使用 rfc3550 定義的 RTP Extension，說明如下： 
如果 image size < 2040*2040，那麼使用原本 rfc2435 定義的欄位來放置 width, height。 
如果 image size 超出 rfc2435 限制(大於2040)，那麼首先設定 RTP header 中的 X-bit(Extension)，表示將使用 RTP 定義的 extension 功能。
接著新增 RTP extension header(ONVIF定義的extension使用0xFFD8當成識別碼)，讓接收端了解此RTP會支援 ONVIF 定義的 JPEG over RTP。此部份請參考下圖。
將 rfc2435 所定義的 RTP/JPEG header 的 width, height 設定為 0。
將正確的 width, height 值設定在 JPEG spec 所定義的 SOF marker 中，並將此 marker 加入 RTP extension payload。
接收端若在 decode 時發現此封包已經設定 X-bit，而且width/height=0，便應該要知道需要去解開 extension payload 中的 SOF marker，並由此得知正確的 width/height.
需注意的是此處的 SOF marker 並非存在於 JPEG 中，而是應該存在於 RTP extension payload。實作時可以直接複製 JPEG 的 SOF marker，當成 RTP extension 即可。  

以下摘錄一個 SOF marker 的例子
FF C0 00 11 08 06 00 08 00 03 01 22 00 02 11 01 03 11 01
SOF marker其說明如下:
標記固定值為 0xFFCO
長度(包含長度本身，但不包含 FFC0)  0x0011=17
精度，每個顏色分量每個圖元的位元數 (bits per pixel per color component)  0x08
圖像高度 0x0600 = 1536
圖像寬度 0x0800 = 2048
顏色分量數(number of color components) 0x03
顏色分量信號(for each component) 01 22 00 02 11 01 03 11 01

三、自己訂
在 SDP中，加入 extension attribute，例如："a=x-CompanyName-Width"，

四、其他網路上的用法
透過 Google 大師，發現網路上慣用的用法有 "x-dimensions" 和 "cliprect"，不過這部份不確定是參考哪份spec制定而成。

註1：H.264可以直接從 SPS 中取得取得 width/height (pic_width_in_mbs_minus1 與 pic_height_in_map_units_minus1)，並不一定要從 RTP header中得知，因此並不會有上述 2040 上限的問題。

註2："x-dimensions" 實作在 live555 的 MediaSession.cpp，摘錄 openRTSP 說明如下：
Alternatively, if the session's SDP description contains the media-level attribute "a=x-dimensions: ,", then these values will be used instead (in which case you won't need to use the "-w" and "-h" options). Similarly, if the session's SDP description contains the media-level attribute "a=x-framerate: ", then this value will be used instead (in which case you won't need to use the "-f" option).

參考資料

1. RTP Payload Format for JPEG 2000 Video Streams (2008/10)
       http://tools.ietf.org/html/rfc5371
2. RTP Payload Format for JPEG-compressed Video (1998/10)
       http://tools.ietf.org/html/rfc2435
3. ONVIF ONVIF-Streaming-Spec-v221.pdf
       chapter 5.1.4 JPEG over RTP
4. RTP: A Transport Protocol for Real-Time Applications
       http://www.ietf.org/rfc/rfc3550.txt
5. http://en.wikipedia.org/wiki/JPEG
   f. http://el.mdu.edu.tw/datacos/09922312044A/JPEG002.pdf 

Referenced from:http://albert-oma.blogspot.com/2013/05/jpeg-extension-when-resolution-20402040.html