gocv MJPEG流适配HTML object尺寸及video元素加载问题咨询

1. object元素内MJPEG流自适应预设宽高实现 #

MJPEG流默认会按原始帧尺寸渲染，不会主动适配容器尺寸，直接通过CSS控制缩放即可，不需要修改后端推流逻辑，性能损耗为0。

实现代码 #

首先给object元素绑定预设尺寸和样式类：

<object
  type="multipart/x-mixed-replace;boundary=frame"
  data="http://你的服务IP:端口/stream"
  class="mjpeg-player"
  width="640"
  height="480"
>
  当前浏览器不支持流加载
</object>

添加CSS控制缩放规则：

.mjpeg-player {
  /* 可以替换为任意你需要的固定尺寸/百分比尺寸，比如width: 100%; height: 100% 适配父容器 */
  width: 640px;
  height: 480px;
  border: none;
  display: block;
  /* 核心缩放属性，根据业务需求选一个即可 */
  object-fit: contain; /* 保持原始宽高比缩放，完整显示所有画面，多余区域留黑 */
  /* object-fit: cover; 保持宽高比缩放，裁剪多余画面填满容器，无黑边 */
  /* object-fit: fill; 强制拉伸填满容器，画面可能变形 */
}

注意：不要为了适配容器尺寸修改Go后端的JPEG编码分辨率，会额外占用CPU编码资源，前端缩放的性能远高于后端实时转码。

2. MJPEG流渲染到原生video元素的可行性 #

结论：原生HTML5 <video> 标签不支持直接播放标准MJPEG over HTTP流，之前尝试失败是浏览器底层机制导致的，不是代码写法问题。
<video> 标签原生仅支持封装格式的流媒体（MP4/WebM/HLS/DASH/WebRTC等），而MJPEG是基于multipart/x-mixed-replace协议拼接的连续JPEG帧，不属于video标签支持的媒体封装格式，没有对应解复用逻辑，无论怎么修改type属性、请求头都无法直接播放。

可行替代方案 #

方案1：零修改后端，前端JS解析流渲染到canvas（推荐，适配你现有代码）

不需要改动现有Go端MJPEG推流逻辑，前端通过Fetch API读取流响应，按MJPEG的boundary分隔符切分独立JPEG帧，逐帧绘制到canvas元素上即可，体验和video标签一致，还可以自定义播放控制、截图、水印等功能，延迟可以控制在100ms以内。
核心实现逻辑：

1. 用fetch请求MJPEG流地址，获取响应的可读流
2. 逐块读取二进制响应内容，匹配你后端设置的帧分隔符，切分出完整的JPEG二进制块
3. 将JPEG块转成Blob URL，赋值给Image对象，加载完成后绘制到canvas上
4. 循环读取下一帧即可实现连续播放

方案2：改造后端编码逻辑，适配video原生支持格式

如果必须用原生video标签，需要放弃MJPEG编码，将gocv采集的帧做如下改造：

• 编码为H.264/AVC格式，封装成fMP4分片，通过HTTP长连接输出CMAF流，video标签设置src为流地址即可直接播放
• 或者集成WebRTC推流逻辑，浏览器端通过RTCPeerConnection拉流播放，延迟可以低到50ms以内
  该方案改造成本较高，需要引入视频编码、封装相关依赖，适合对延迟、兼容性要求高的场景。

避坑提示：不要尝试用<img>标签直接加载MJPEG流实现播放，虽然部分浏览器兼容该写法，但无法控制帧刷新节奏，播放时间长了会出现延迟累积、内存泄漏问题。

内容的提问来源于stack exchange，提问作者Hasan A Yousef