Javascript multipart/x-mixed-replace PNG流始终显示上一帧之前的帧
制作了一个程序,通过Javascript multipart/x-mixed-replace PNG流始终显示上一帧之前的帧,javascript,http,go,multipart-mixed-replace,Javascript,Http,Go,Multipart Mixed Replace,制作了一个程序,通过多部分/x-mixed-replace内容类型标题将PNG图像流到浏览器,我注意到,标记中只显示上一帧,而不是最近发送的帧 这种行为非常烦人,因为我只在图像更改以节省带宽时发送更新,这意味着在我等待更新时屏幕上会出现错误的帧 具体地说,我使用的是Brave浏览器(基于chromium),但正如我尝试过上下使用“屏蔽”一样,我认为这个问题至少在其他基于chromium的浏览器中也会出现 搜索这个问题只会产生一个相关的结果(以及许多不相关的结果),这就是HowToForge线程,
多部分/x-mixed-replace
内容类型
标题将PNG图像流到浏览器,我注意到,
标记中只显示上一帧,而不是最近发送的帧
这种行为非常烦人,因为我只在图像更改以节省带宽时发送更新,这意味着在我等待更新时屏幕上会出现错误的帧
具体地说,我使用的是Brave浏览器(基于chromium),但正如我尝试过上下使用“屏蔽”一样,我认为这个问题至少在其他基于chromium的浏览器中也会出现
搜索这个问题只会产生一个相关的结果(以及许多不相关的结果),这就是HowToForge线程,没有回复。同样,我也认为问题与缓冲有关,但我确保刷新缓冲区无效,这与线程中的用户非常相似。用户确实报告说它在他们的一台服务器上工作,而不是在另一台服务器上,这让我相信它可能与特定的HTTP头或类似的东西有关。我的第一个猜测是内容长度
,因为浏览器可以从中判断图像何时完成,但它似乎没有任何效果
所以本质上,我的问题是:有没有办法告诉浏览器显示最新的多部分/x-mixed-replace
而不是以前的?如果这不是标准行为,原因可能是什么
当然,这里是相关的源代码,尽管我认为这更像是一个一般的HTTP问题,而不是与代码有关的问题:
服务器
多部分MIME消息中的一部分以MIME头开始,以边界结束。在第一个实部之前有一个单一的边界。此初始边界关闭MIME前导 相反,您的代码假定零件以边界开始。基于此假设,首先发送边界,然后发送MIME头,然后发送MIME正文。然后停止发送,直到下一部分准备就绪。因此,只有在发送下一个零件时,才会检测到一个零件的末端,因为只有在发送下一个零件时,才会发送上一个零件的末端边界
要解决这个问题,代码应该首先发送一个边界来结束MIME前导。对于每个新的部分,它应该发送MIME头、MIME正文,然后是结束该部分的边界。多部分MIME消息中的部分以MIME头开始,以边界结束。在第一个实部之前有一个单一的边界。此初始边界关闭MIME前导 相反,您的代码假定零件以边界开始。基于此假设,首先发送边界,然后发送MIME头,然后发送MIME正文。然后停止发送,直到下一部分准备就绪。因此,只有在发送下一个零件时,才会检测到一个零件的末端,因为只有在发送下一个零件时,才会发送上一个零件的末端边界
要解决这个问题,代码应该首先发送一个边界来结束MIME前导。对于每个新的部分,它都应该发送MIME头、MIME正文,然后发送结束该部分的边界。我遇到了同样的问题:使用
多部分/x-mixed-replace时有1帧延迟。
这个问题似乎出现在Chrome中,它似乎与multipart/x-mixed-replace
资源相关。Firefox中不存在此问题
因此,要“欺骗”Chrome显示视频流,唯一的方法是将每个图像发送两次,否则会有1帧延迟。
如前所述,Firefox中不存在问题。我也有同样的问题:使用
multipart/x-mixed-replace时有1帧延迟
这个问题似乎出现在Chrome中,它似乎与multipart/x-mixed-replace
资源相关。Firefox中不存在此问题
因此,要“欺骗”Chrome显示视频流,唯一的方法是将每个图像发送两次,否则会有1帧延迟。
如前所述,Firefox中不存在此问题。听起来可能是缓存问题。通过添加一些随机垃圾作为get参数,使img.src url唯一。@John我想到了这一点,但图像确实改变了,只是改变了一帧太晚,所以它不太可能缓存IMO。除此之外,在程序重新启动(这是一个get参数)之间,令牌会发生变化,从而在某种程度上停止缓存,然后我还添加了缓存控制:no Cache
标题,这是一个很好的度量。听起来可能是缓存问题。通过添加一些随机垃圾作为get参数,使img.src url唯一。@John我想到了这一点,但图像确实改变了,只是改变了一帧太晚,所以它不太可能缓存IMO。除此之外,在程序重新启动(这是一个get参数)之间,令牌会发生变化,从而在某种程度上停止缓存,然后我还添加了缓存控制:no Cache
标题,这是一个很好的度量。很抱歉延迟了,谢谢你的回答。我想我实际上试过了一些你在提问前描述的东西,但似乎不起作用,所以我在最后测试了边界。不管怎样,你说的似乎是对的,但即使改变了,我也有同样的问题。我做了一些cURL调试,发现当我在末尾包含边界时,它直到下一个请求仍然不会被发送,甚至是同一字节片的一部分。知道为什么吗?我意识到我写的东西可能很难理解,所以下面是答案,希望能澄清。问题是,尽管我现在正在发送--frame
预告片,但由于某些原因,它实际上并未被发送。进一步的更新—在末尾添加两个换行符(在--frame
之后)解决了这个问题
package routes
import (
"crypto/md5"
"fmt"
"image/color"
"net/http"
"time"
brain "path/to/image/generator/module"
)
func init() {
RouteHandler{
function: func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "multipart/x-mixed-replace; boundary=frame")
w.Header().Set("Cache-Control", "no-cache") // <- Just in case
w.WriteHeader(200)
// If the request contains a token and the token maps to a valid "brain", start consuming frames from
// the brain and returning them to the client
params := r.URL.Query()
if val, ok := params["token"]; ok && len(val) > 0 {
if b, ok := SharedMemory["brains"].(map[string]*brain.Brain)[val[0]]; ok && !b.CheckHasExit() {
// Keep a checksum of the previous frame to avoid sending frames which haven't changed. Frames cannot
// be compared directly (at least efficiently) as they are slices not arrays
previousFrameChecksum := [16]byte{}
for {
if !b.CheckHasExit() {
frame, err := b.GetNextFrame(SharedMemory["conf"].(map[string]interface{})["DISPLAY_COL"].(color.Color))
if err == nil && md5.Sum(frame) != previousFrameChecksum {
// Only write the frame if we succesfully read it and it's different to the previous
_, err = w.Write([]byte(fmt.Sprintf("--frame\r\nContent-Type: image/png\r\nContent-Size: %d\r\n\r\n%s\r\n", len(frame), frame)))
if err != nil {
// The client most likely disconnected, so we should end the stream. As the brain still exists, the
// user can re-connect at any time
return
}
// Update the checksum to this frame
previousFrameChecksum = md5.Sum(frame)
// If possible, flush the buffer to make sure the frame is sent ASAP
if flusher, ok := w.(http.Flusher); ok {
flusher.Flush()
}
}
// Limit the framerate to reduce CPU usage
<-time.After(time.Duration(SharedMemory["conf"].(map[string]interface{})["FPS_LIMITER_INTERVAL"].(int)) * time.Millisecond)
} else {
// The brain has exit so there is no more we can do - we are braindead :P
return
}
}
}
}
},
}.Register("/stream", "/stream.png")
}
function start() {
// Fetch the token from local storage. If it's empty, the server will automatically create a new one
var token = localStorage.getItem("token");
// Create a session with the server
http = new XMLHttpRequest();
http.open("GET", "/startsession?token="+(token)+"&w="+(parent.innerWidth)+"&h="+(parent.innerHeight));
http.send();
http.onreadystatechange = (e) => {
if (http.readyState === 4 && http.status === 200) {
// Save the returned token
token = http.responseText;
localStorage.setItem("token", token);
// Create screen
var img = document.createElement("img");
img.alt = "main display";
// Hide the loader when it loads
img.onload = function() {
var loader = document.getElementById("loader");
loader.remove();
}
// Start loading
img.src = "/stream.png?token="+token;
// Start capturing keystrokes
document.onkeydown = function(e) {
// Send the keypress to the server as a command (ignore the response)
cmdsend = new XMLHttpRequest();
cmdsend.open("POST", "/cmd?token="+(token));
cmdsend.send("keypress:"+e.code);
// Catch special cases
if (e.code === "Escape") {
// Clear local storage to remove leftover token
localStorage.clear();
// Remove keypress handler
document.onkeydown = function(e) {}
// Notify the user
alert("Session ended succesfully and the screen is inactive. You may now close this tab.");
}
// Cancel whatever it is the keypress normally does
return false;
}
// Add screen to body
document.getElementById("body").appendChild(img);
} else if (http.readyState === 4) {
alert("Error while starting the session: "+http.responseText);
}
}
}