5 ms·
Am I missing a trick or does this only work when the only thing you're serving at that HTTP server is the JPEG image of the camera? Otherwise the user later ref
by pedrocr 12y ago
Am I missing a trick or does this only work when the only thing you're serving at that HTTP server is the JPEG image of the camera? Otherwise the user later refreshes the page thus doing a "GET / HTTP/1.1" and gets /image.jpg instead.
- jacquesm 12y agoYes, you're missing a trick. The url was modified on each request to bust the caches in between.
- pedrocr 12y agoBut how will that work if you're sending the response before you parse the request? You don't know the URL the client is after. Were you relying on the browser keeping the same connection alive so you always went index.html->jpegs?
- jacquesm 12y agoThe cam only sends out images, it can't really do much else. So you don't need to know the request, it is implicit.
- pedrocr 12y agoRight, what I meant was that you can't have the camera serve a nice /index.html with the embedded image and other niceties like modern IP cameras do, because you reply with an image to every request.
- jacquesm 12y agoWell, you can actually. All you need to do is switch modes after the first request, which you handle like every other. Which is in fact what it did... The idea here is that once you've received one request for an image all subsequent requests on that socket will be images as well.
- pedrocr 12y agoOk, then you are relying on multiple requests on a single socket, which was what I had suggested before. Does that work reliably though if the user reloads the page while it's streaming? Wouldn't the browser reuse the same connection to request the HTML page again and get an image instead?