http - MJPEG over HTTP 规范

Question

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

In response to a GET request for a MJPEG file or stream, the server streams the sequence of JPEG frames over HTTP. A special mime-type content type multipart/x-mixed-replace;boundary=<boundary-name> informs the client to expect several parts (frames) as an answer delimited by <boundary-name>. This boundary name is expressly disclosed within the MIME-type declaration itself.

但这在实践中似乎不是很准确。我转储了一些流以了解它们的行为方式。大多数流具有以下格式(其中 CRLF 是回车换行符，部分 header 是一些没有状态行的 header 字段):

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 header ，类型设置为 multipart/x-mixed-replace .

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

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

这让我很恼火，所以我想到了另一种获取帧的方法。

因为每个 JPEG 都以 0xFF 0xD8 开头作为图像标记的开始并以 0xFF 0xD9 结束我可以开始寻找这些。这似乎是一种非常肮脏的方法，我不太喜欢它，但它可能是最可靠的方法。

在我开始实现它之前，关于基于 HTTP 的 MJPEG，我是否遗漏了一些要点？是否有通过 HTTP 传输 MJPEG 的任何实际规范？仅观察 JPEG 的开始和结束标记而不是使用边界来分隔帧时有什么注意事项？

Answer 1

this doesn't seem to be very accurate in practice.

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

The first frame never contained actual image data.

是的，确实如此。在第一个 MIME 实体之前总是有一个起始边界(因为 MIME 可以在第一个实体之前包含序言数据)。您认为 MIME 边界仅存在于每个 MIME 实体之后，但事实并非如此。

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

Actual frame data CRLF
(Sometimes here is an optional CRLF)
Boundary

实际上，最后一个 CRLF 不是可选的，它实际上是跟随 MIME 实体数据的下一个边界的一部分(参见 RFC 2046 Section 5)。 MIME 边界必须出现在它们自己的行上，因此在实体数据之后人为地插入了一个 CRLF，这对于不会自然地由它们自己的 CRLF 终止的数据类型(如图像)尤为重要。

Two Servers claimed boundary="MOBOTIX_Fast_Serverpush" but then used --MOBOTIX_Fast_Serverpush as frame delimiter

这就是 MIME 应该 的工作方式。 Content-Type header 中指定的boundary 在实际实体流中总是以-- 为前缀，并且最后一个实体之后的终止边界也以 -- 为后缀。

例如:

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--

This irritated me quite a bit so I though of an other approach to get the frames.

你想的是行不通的，也没有你想的那么稳健。您确实需要正确地处理 MIME 流。

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

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