视频编解码类型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被广泛应用在网页浏览器，媒体播放器，数字相机，摄像头，流媒体服务器和非线性剪辑系统中。

摄像头基于ONVIF协议的介绍 什么是ONVIF协议
2008年5月，由安讯士（AXIS）联合博世（BOSCH）及索尼（SONY）公司三方宣布携手共同成立一个国际开放型网络视频产品标准网络接口开发论坛，取名为ONVIF（Open
Network Video Interface
Forum，开放型网络视频接口论坛）并以公开、开放的原则共同制定开放性行业标准。ONVIF标准将为网络视频设备之间的信息交换定义通用协议，包括装置搜寻、实时视频、音频、元数据和控制信息等。

ONVIF规范中设备管理和控制部分所定义的接口均以Web
Services的形式提供，设备作为服务提供者为服务端。ONVIF规范涵盖了完全的基于XML及WSDL的定义。每一个支持ONVIF规范的终端设备均须提供与功能相应的Web
Service。服务端与客户端的数据交互采用SOAP协议。ONVIF中的其他部分比如音视频流则通过RTP/RTSP进行 。

ONVIF规范 ONVIF规范向视频监控引入了Web Service的概念。设备的实际功能均被抽象为了Web
Service的服务，视频监控系统的控制单元以客户端的身份出现，通过Web请求的形式完成控制操作。 A:Web
Service能为视频监控什么

设备的无关性，任何一个设备接入系统，不会对其他系统造成影响。
设备的独立性，每一个设备只负责对接收到的请求做出反馈，甚至不需要知晓控制端的存在。 管理的集中性，所有的控制由客户端来发起。

B:ONVIF规范能为视频监控带来什么

抽象了功能的接口。统一了对设备的配置以及操作的方式。 控制端关心的不是设备的型号，而是设备所提供的Web Service。
规范了视频系统中Web Service范围之外的行为。 ONVIF提供了各个模块的WSDL，拥有效率非常高的开发方式。

C:ONVIF规范的内容

设备发现 设备管理 设备输入输出服务 图像配置 媒体配置 实时流媒体 接收端配置 显示服务 事件处理 PTZ控制 其他

Referenced from:https://blog.csdn.net/zong596568821xp/article/details/89645038

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