html 中的 JPEG 直播流很慢

Question

From a raw video source I'm trying to stream jpeg images to html as fast as possible in a embedded platform/board using linux.从原始视频源，我试图在使用 linux 的嵌入式平台/板中尽可能快地将 jpeg 图像流式传输到 html。

At the gstreamer side I can see that the jpeg image is updated at ~37fps the pipeline looks like this:在 gstreamer 端，我可以看到 jpeg 图像以 ~37fps 更新，管道如下所示：

appscr -> videoconvert -> jpegenc -> multifilesink

based in this question I created the next embedded html:基于这个问题，我创建了下一个嵌入式 html：

<!DOCTYPE html>
<html>
    <head>
        <meta charset='UTF-8' />
        <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>
        <script src="app.js"></script>
    </head>
    <body>  
        <img id="snapshot" src="snapshot.jpeg"/>
    </body>
</html>

and the java script:和java脚本：

$(function() {
    function refreshImage(){
    $("#snapshot").attr("src", 'snapshot.jpeg?' + Math.random());
    setTimeout(refreshImage, 20);
    }
    refreshImage();
})

Opening a web browser from a PC and typing the platform/board IP I can see the video stream, but the problem is that the image is updated too slow and I would expect a more fluid/fast video given the source frame rate (37fps).从 PC 打开 Web 浏览器并输入平台/主板 IP 我可以看到视频流，但问题是图像更新速度太慢，鉴于源帧速率 (37fps)，我希望视频更流畅/更快.

does anyone know what could be the reason why the update is slow?有谁知道更新缓慢的原因可能是什么？

Answer 1

I think this deserves proper analysis since it is interesting subject (at least for me).我认为这值得适当的分析，因为这是一个有趣的主题（至少对我而言）。

Testing environment测试环境

I completely replicated scenario on 2 PCs within same LAN.我在同一局域网内的 2 台 PC 上完全复制了场景。

PC 1 is creating jpeg images from live stream with following pipeline PC 1正在使用以下管道从实时流创建 jpeg 图像

gst-launch-1.0 -v rtspsrc location="rtsp://freja.hiof.no:1935/rtplive/_definst_/hessdalen03.stream" \
! rtph264depay ! avdec_h264 \
! timeoverlay halignment=right valignment=bottom \
! videorate ! video/x-raw,framerate=37000/1001 ! jpegenc ! multifilesink location="snapshot.jpeg"

and serving index.html, app.js and (endlessly updated) snapshot.jpeg with python's simple http server并使用 python 的简单 http 服务器提供 index.html、app.js 和（不断更新的）snapshot.jpeg

python -m SimpleHTTPServer 8080

PC 2 is accessing index.html using Chrome browser (with developer tools window) and showing images. PC 2正在使用 Chrome 浏览器（带有开发人员工具窗口）访问 index.html 并显示图像。

For testing purposes用于测试目的

I've added timeoverlay in gstreamer pipeline that adds timestamp on each image in right bottom corner.我已经添加timeoverlay GStreamer的管道，在右下角的每个图像上添加时间戳。
I increased refresh period in JS function on 1000 ms.我在 JS 函数中增加了 1000 毫秒的刷新周期。

Analysis of test results测试结果分析

Here is browser's network log这是浏览器的网络日志

Time column shows periods (in ms) that browser spends to fetch (download) one image from server.时间列显示浏览器从服务器获取（下载）一张图像所花费的时间段（以毫秒为单位）。 Those periods are not always the same with average of ~100ms for images with size ~87KB.对于大小约为 87KB 的图像，这些周期并不总是相同，平均约为 100 毫秒。

Fetch time interval actually includes:获取时间间隔实际上包括：

interval that HTTP GET needs to reach server from browser, HTTP GET 需要从浏览器到达服务器的时间间隔，
interval that server needs to read image from disk and send it back as HTTP response,服务器需要从磁盘读取图像并将其作为 HTTP 响应发送回的时间间隔，
interval that HTTP response needs to reach browser. HTTP 响应到达浏览器所需的时间间隔。

1st and 3rd interval are directly depend on "internet" environment: if browser is "farther" away from server interval will be greater.第一个和第三个间隔直接取决于“互联网”环境：如果浏览器离服务器“更远”，则间隔会更大。

2nd interval is proportional to server "speed": how fast server can read images from disk and handle HTTP request/response第二个间隔与服务器“速度”成正比：服务器从磁盘读取图像和处理 HTTP 请求/响应的速度

There is another interval proportional to "speed" of PC which runs browser: how fast PC can handle HTTP GET request/response and re-render image.还有一个与运行浏览器的 PC 的“速度”成正比的间隔：PC 处理 HTTP GET 请求/响应和重新渲染图像的速度。

Conclusion结论

There are many unavoidable delay intervals that depend on testing environment - internet and capabilities of server machine and client machine with browser - and your code in browser is executing as fast as it possibly can.有许多不可避免的延迟间隔取决于测试环境 - 互联网和服务器机器和带有浏览器的客户端机器的功能 - 并且您在浏览器中的代码正在尽可能快地执行。

In any case, 37 fps sounds like some live stream video .无论如何， 37 fps 听起来像一些直播视频。 There are specialized protocols to stream video that can be shown in browser (eg MPEG DASH or HLS ) by serving video chunk-by-chunk (where each chunk contains many video frames).有专门的协议可以通过逐块提供视频（其中每个块包含许多视频帧）来流式传输视频（例如MPEG DASH或HLS ）。

html 中的 JPEG 直播流很慢

问题描述

1 个解决方案

解决方案1
1 已采纳 2020-01-25 13:30:14

html 中的 JPEG 直播流很慢

问题描述

1 个解决方案

解决方案1 1 已采纳 2020-01-25 13:30:14

解决方案1
1 已采纳 2020-01-25 13:30:14