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

互联网工程任务组是一个开放的标准组织,负责开发和推广自愿互联网标准,特别是构成TCP/IP协议族的标准。 它没有正式的会员资格或会员资格要求。 所有参与者和经理都是志愿者,尽管他们的工作通常由雇主或赞助商资助。 维基百科
创立于: 1986 年 1 月 14 日
总部: 美国加利福尼亚費利蒙
上级组织: 网际网路协会
类型: 非营利组织; 标准组织
简称: IETF
子公司: 互联网架构委员会, 互联网工程指导组, IETF Administrative Oversight Committee
母公司/上级机构: 互联网协会

热点聚焦:中国监管层“双维护”基调纾困房地产业 政策向刚需按揭倾斜 | 路透
update:2021-9-30
中国恒大危机爆发后,中国金融监管层近日首提“双维护”,给处于困局中的房地产行业带来了一些曙光。市场分析认为,不能把这次会议的基调理解为对房地产市场调控的放松,只是严管控政策迎来了边际转变,预计房地产融资端环境有望小幅缓和,住房按揭贷款政策松绑最为必要,将会先行。

拥有1.9万亿元庞大债务的中国恒大陷入债券兑付危机,引发整个中国房地产业风声鹤唳,中国同策研究院研究总监宋红卫说,“(央行)再不出手,可能年内还有几十家企业要倒。”

今年以来,中国房地产企业在“三道红线”、贷款集中度、三线四档等政策下爆雷不断,华夏幸福、泰禾、蓝光发展、中国恒大相继陷入资金链断裂困局。

“央行这不是’救市’,而是在维稳,”宋红卫称。

他表示,目前房地产政策不大可能出现整体性放松。宏观审慎相机抉择的调控手段就是要求根据市场实际情况来调整,过度的收紧不利于房地产市场的稳定。

中国央行第三季度货币政策例会上提出要“维护房地产市场的健康发展,维护住房消费者的合法权益”。两天后,央行、银保监会联合召开房地产金融工作座谈会,指出“金融机构要按照法治化、市场化原则,配合相关部门和地方政府共同维护房地产市场的平稳健康发展,维护住房消费者合法权益”。

宋红卫并指出,央行连续两次发声力挺房地产,有两个方面的影响,一是给房地产市场稳定预期,目前整个行业面临抽贷,断贷以及产业链停工的现象。二是最核心方面,四季度贷款额度紧张的局面有可能会缓解。对于房地产市场来讲是利好。

“央行罕见提及房地产...预计未来融资端环境或有望迎来小幅缓和,”平安证券分析师杨侃表示。

“房地产调控不会放松,但也不是线性收紧的趋势,到了某个阶段就到了政策稳定的阶段,”渣打银行首席经济学家、大中华区研究部主管丁爽称,“特别是‘三道红线’,现在越来越多企业慢慢往黄或绿转变,达标的企业面临的信贷环境会慢慢改善。”

中国官媒经济日报周三发表评论文章称,不能因为个别房企和个别城市房地产市场出现一些新情况,就轻言放松调控;“房住不炒”,“稳地价、稳房价、稳预期”的政策主基调不应也不会改变。

“目前整个融资处于半瘫痪了,”宋红卫指出,现在能发出债的房地产企业不超过五家,而信托去年就在收紧;甚至原本可以垫资的建造商现在也不让垫资,也侧面给企业增加了现金流压力。

不同政策有交叉影响,“三条红线”要求现金流覆盖短期债务,但是“两集中”供地政策又造成现金流集中支出,短时间又踩上了“三条红线”。

市场人士分析认为,房地产融资端可能出现微调,住房按揭贷款可能率先调整。“关注按揭端放款速度及利率的变化”,杨侃表示,比如放宽按揭贷款审批条件、缩短按揭贷款放款周期等,目前新房放款周期普遍在3-6个月,二手房更长。这将带来销售回款端资金改善,利于保障住房刚需消费。

楼市刚需将优先满足

中国住房按揭贷款可能成为高压政策放松的窗口。官方媒体经济参考报等均发声指出“防止政策调整误伤合理的市场需求”、“楼市调控应注意满足刚需”。

以此来看,住房消费者获得正常的按揭贷款,以及正常(不加价的)按揭贷款利率的可能性增加。

中国银保监会9月份初也提到,银保监会将督促银行机构在贷款首付比例、利率等方面对刚需群体进行差异化支持。

“中短期来讲,当前基本面加速下行背景下,有增加刚需按揭支持基本面防风险必要;中长期来讲,有一定的需要刚需按揭创造信用功能的必要。” 兴业证券分析师靳璐瑜、阎常铭在联合撰写的报告中称。

他们并表示,几乎所有海外经济体,在经济增长面临一些压力情况下,不同程度的依靠地产创造信用。中国在去供给端杠杆后,未来支持刚需群体的按揭可能更多的承担信用创造功能。

“(放松按揭贷款)一部分解决了刚需买房的问题,同时提供房企适度的健康的资金链循环窗口,若各个环节都堵死了,那就真的完了,”宋红卫称。

中国央行原行长周小川日前在复旦大学首席经济学家论坛上演讲还指出,住房贷款是一个非常重要的有收入再分配功能的金融业务。

周小川说,“往往富裕的人可能是全款买房,同时存款比较多,大家往往说80%的存款是20%的人存的,这些存款可以支持中低收入的人贷款买房,这样实际上有非常好的收入分配的作用。”
Referenced from:https://cn.reuters.com/article/china-real-estate-market-cen-loan-0930-idCNKBS2GQ08D?il=0

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