java mjpeg_MJPEG over HTTP规范

博客作者在尝试创建一个工具来从HTTP传输的MJPEG流中提取帧,发现实际行为与维基百科描述的标准不完全一致。他们遇到的问题包括服务器使用不匹配的帧分隔符和依赖于JPEG开始和结束标记来分割帧的潜在问题。作者考虑使用JPEG标记作为分割依据,尽管这种方法可能不理想,但可能是最可靠的。博客探讨了HTTP传输MJPEG的规范缺失以及应对不一致性的方式。
摘要由CSDN通过智能技术生成

我试图创建一个工具来从通过http传输的mjpeg流中获取帧 . 我没有找到任何规范,所以我看了维基百科说的here:

为响应对MJPEG文件或流的GET请求,服务器通过HTTP流式传输JPEG帧序列 . 一个特殊的mime类型内容类型multipart / x-mixed-replace; boundary = 通知客户端期望几个部分(帧)作为分隔的答案 . 此边界名称在MIME类型声明本身中明确公开 .

但这在实践中似乎并不十分准确 . 我抛弃了一些流来了解它们的行为方式 . 大多数流具有以下格式(其中 CRLF 是回车换行符,部分 Headers 是一些没有状态行的 Headers 字段):

Status line (e.g. HTTP/1.0 200 OK) CRLF

Header fields (e.g. Cache-Control: no-cache) CRLF

Content-Type header field (e.g. Content-Type: multipart/x-mixed-replace; boundary=--myboundary) CRLF

CRLF (Denotes that the header is over)

Boundary (Denotes that the first frame is over) CRLF

Partial header fields (mostly: Content-type: image/jpeg) CRLF

CRLF (Denotes that this "partial header" is over)

Actual frame data CRLF

(Sometimes here is an optional CRLF)

Boundary

Starting again at partial header (line 6)

第一帧从不包含实际图像数据 . 所有分析的流都具有Content-Type标头,类型设置为 multipart/x-mixed-replace .

但是有些流在这里弄错了:

两台服务器声称 boundary="MOBOTIX_Fast_Serverpush" 但后来使用 --MOBOTIX_Fast_Serverpush 作为帧分隔符 .

这让我非常恼火,所以我想采用另一种方法来获得帧 .

由于每个JPEG以 0xFF 0xD8 作为图像开始标记开始,以 0xFF 0xD9 结束,我可以开始寻找这些 . 这似乎是一种非常肮脏的方法,我不是很喜欢它,但它可能是最强大的方法 .

在我开始实现之前,我是否有一些关于MJPEG通过HTTP错过的观点?是否有通过HTTP传输MJPEG的真实规范?只是观察JPEG的开始和结束标记而不是使用边界来分隔帧时有什么注意事项?

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值