MJPEG over HTTP规范

Question

我试图创建一个工具来从通过HTTP传输的mjpeg流中获取帧。我没有找到任何规范，所以我看了一下维基百科在这里说的话：

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

但这在实践中似乎并不十分准确。我转储了一些流，以了解它们的行为。大多数流具有以下格式（其中CRLF有回车换行符，部分标头是不带状态行的某些标头字段）：

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所以我可以开始寻找这些图像。这似乎是一种非常肮脏的方法，我不太喜欢它，但它可能是最可靠的方法。

在开始实施此功能之前，我是否缺少关于HTTP上的MJPEG的几点知识？是否有通过HTTP传输MJPEG的真实规范？仅注意JPEG的开始和结束标记而不是使用边界定界帧时的注意事项是什么？

Answer 1

在实践中这似乎不是很准确。

在实践中这是非常准确的。您只是没有正确处理它。

第一帧从不包含实际图像数据。

是的，它确实。有总是一个起始边界之前第一MIME实体（作为MIME能够在第一实体之前包含序幕数据）。您认为只存在MIME边界后，每个MIME实体，但是这是不正确的。

我建议您阅读MIME规范，尤其是RFC 2045和RFC 2046。在这种情况下，MIME可以正常工作，您只是无法正确解释结果。

实际帧数据CRLF
（有时是可选的CRLF）
边界

实际上，最后一个CRLF不是可选的，它实际上是MIME实体数据后面的下一个边界的一部分（请参阅RFC 2046第5节）。MIME边界必须出现在它们自己的行上，因此CRLF被人为地插入到实体数据之后，这对于不自然地被其自己的CRLF终止的数据类型（例如图像）尤其重要。

两台服务器已声明所有权，boundary="MOBOTIX_Fast_Serverpush"但随后用作--MOBOTIX_Fast_Serverpush帧定界符

MIME 应该就是这样工作的。的boundary在指定的Content-Type报头总是与前缀--的实际实体流中，最后实体之后终止边界也后缀--为好。

例如：

Content-Type: multipart/x-mixed-replace; boundary="MOBOTIX_Fast_Serverpush"

--MOBOTIX_Fast_Serverpush
Content-Type: image/jpeg

<jpeg bytes>
--MOBOTIX_Fast_Serverpush
Content-Type: image/jpeg

<jpeg bytes>
--MOBOTIX_Fast_Serverpush
... and so on ...
--MOBOTIX_Fast_Serverpush--

这让我非常恼火，因此我还是采用了另一种获取框架的方法。

您正在考虑的内容将不起作用，并且不如您所考虑的那样健壮。您确实需要正确地处理MIME流。

处理时multipart/x-mixed-replace，您应该做的是：

1. 读取并丢弃HTTP响应正文，直到到达Content-Type响应标头指定的第一个MIME边界为止。
2. 然后读取MIME实体的标头和数据，直到到达下一个匹配的MIME边界。
3. 然后根据其标题（例如，在image/jpeg屏幕上显示实体）根据需要处理实体的数据。
4. 如果尚未关闭连接，并且最后读取的边界不是终止边界，请返回2，否则停止处理HTTP响应。