4 ms·
The code creates a new buffer for each frame and then pushes that into the gif. There is no freeing of memory or any kind of ring buffer being setup. So yes, it
by MarkHarmon 13y ago
The code creates a new buffer for each frame and then pushes that into the gif. There is no freeing of memory or any kind of ring buffer being setup. So yes, it keeps eating memory.
- codereflection 13y agoPerhaps a periodic page refresh would work around the issue. Then that brings up another question, is any part of the gif cached by the browser or downstream proxies / web accelerators?
- lightblade 13y agoThe client side could wrap the gif image in iframe to control the refresh.
- camus 13y agoi saw a site linked on HN that was using that kind of technique to siplay public camera feeds, if anyone remember the link , would be great to share it again.
- flippyhead 13y agoI'd like to see this too
- darsham 13y agoyou're probably thinking about this (which now 404s): http://cryptogasm.com/webcams/ http://cryptogasm.com/webcams/ Don't know why it was taken down. Here is the old thread : https://news.ycombinator.com/item?id=5543465 https://news.ycombinator.com/item?id=5543465 which mentions the Content-Type "multipart/x-mixed-replace" technique used to constantly update jpegs in the browser.
- nairteashop 13y agoSecurity cameras use MJPEG (Motion JPEG), which works quite similarly to animated GIFs. They're very easy to find as most vendors have a URL pattern. For example, here're a bunch of public security cameras made by Axis: https://www.google.com/#output=search&q=inurl:axis-cgi%2Fmjpg%2Fvideo.cgi&oq=inurl:axis-cgi%2Fmjpg%2Fvideo.cgi https://www.google.com/#output=search&q=inurl:axis-cgi%2...
- jorde 13y agoI wonder if this could be used as a way to crash browsers if there's no check for image sizes? Most sites allow user submitted images and over time one could stream big enough gif (...err jif) to crash idle tabs.