MJPEG over HTTP 规范
MJPEG over HTTP Specification
我试图创建一个工具来从通过 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 是回车符 return 换行符，部分 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 的开始和结束标记而不是使用边界来分隔帧，有什么注意事项？
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 and 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-Typeheader中指定的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 时，您应该 做的是：
- 读取并丢弃 HTTP 响应 body，直到到达
Content-Type 响应指定的第一个 MIME 边界 header。
- 然后读取 MIME 实体的 headers 和数据，直到到达下一个匹配的 MIME 边界。
- 然后根据其 header 的需要处理实体的数据（例如，在屏幕上显示
image/jpeg 实体）。
- 如果连接还没有关闭，并且最后读取的边界不是终止边界，则返回2，否则停止处理HTTP响应。
我试图创建一个工具来从通过 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 是回车符 return 换行符，部分 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 的开始和结束标记而不是使用边界来分隔帧，有什么注意事项？
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 and 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_Serverpushas frame delimiter
这就是 MIME 应该 工作的方式。 Content-Typeheader中指定的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 时，您应该 做的是：
- 读取并丢弃 HTTP 响应 body，直到到达
Content-Type响应指定的第一个 MIME 边界 header。 - 然后读取 MIME 实体的 headers 和数据，直到到达下一个匹配的 MIME 边界。
- 然后根据其 header 的需要处理实体的数据（例如，在屏幕上显示
image/jpeg实体）。 - 如果连接还没有关闭，并且最后读取的边界不是终止边界，则返回2，否则停止处理HTTP响应。