Can't help thinking
There musy be some nasty potential - or at least inspiration -for malware here...
However you choose to pronounce GIF, developer Andrey Sidorov has found a great new use for the recently-resurgent-thanks-to-Tumblr file format: displaying a remote device. Sidorov used the weekend just passed to unleash a tool called VNC-over-GIF that does what is says on the can. For the uninitiated, Virtual Network Control …
As I understand it, RDP is more like X than VNC - the drawing commands are sent across the wire, not the results of the drawing. So comparing RDP to VNC is like comparing apples to DRAMs.
Again, I cannot speak for RDP, but I know that X does better over lower bandwidth links with low latency, but VNC works where X falls down, which is links with insufficient bandwidth to carry all the drawing commands. X will just die on such a link, RDP will just update slowly.
GIF supports custom data blocks so you can easily embed extra information into the file without breaking other readers.
GIF allows you to build up changes ontop of a previous image so is naturally quite suited to this sort of application. Though it's still limited to 256 colours
Probably he had to change the ENCODER library, not the decoder. The encoder had to be changed to accept a potentially endless stream of delta frames.
The decoder already has that, as there is nothing in the GIF header that tells the decoder how big the image will be - you decode until you hit EOF>.
What's the advantage over the ancient already MJPEG (NOT MPEG) format?
I suppose 256 colours + palette is acceptable instead of full colour and no palette.
Of course MJPEG was designed for files not streaming, but unlike GIF was envisaged to be used for video.
This is unlikely to work with any GIF viewer as they expect a file and can't read a stream. Also there is a hardly used animated version of PNG, The APNG format supports 24 bit and transparency as well as 256 colour palettes. Surely a better starting point if you don't like MJPEG (i.e. licence conditions or content non-photographic)?
An MPEG-TS can in theory be used for streaming M-APNG or M-GIF variant, MJPEG etc and not just MPEG1, MPEG2, MPEG4 etc as it's just a multiplex envelope and has advantage it can do sound, non-image data (IP Broadcast or non-IP, even Unicast using DOCSIS) etc all in same stream.
At least he admits he can't see the point of it!
As far as I'm aware, MJPEG is basically a whole shatload of jpeg pictures arranged in a container. So, for every new frame, you have to send the whole screen. IIRC animated GIFs are, in most cases, sent as a bunch of delta values, so only what has changed since the last frame is sent over the wire.
If you were streaming video, then MJPEG would probably be better (though nowhere near as good as one of the MPEG standards). For something where the only thing that might have changed is the mouse pointer though, animated GIF is probably better.
Though yes, the whole thing seems to have been "because it's cool" rather than "because it makes sense."
JPEG assumes an image has few high frequency components. Images like this text look very ugly on JPEG as you lose the high frequency components that make the letter sharp.
GIF, PNG, and such make no such assumptions - so yes, they don't compress as much, but you don't turn letters into artifact soup.
It's not well known, but gifs *can* contain more than 256 colours. The restriction is that the image be divided into contiguous rectangles (pixel dimensions of your choice) and *these* should have the same (max 256 colour) palette. So the top half of the gif could be greyscale and the bottom half could be 'vivid' or whatever those funny old names for cluts were. You can have as many of these blocks as you want. Presumably you could have 1x1 pixel blocks, each with their own palette but then it would scarcely be efficient compression. Still it's a nice hack not a million miles from Amiga's ingenious HAM. Unfortunately there are very few tools which support the export of such exotic objects. Browser support is pretty good however. There's a page on the web which shows off the technique. Can't be arsed to google for it though.
Give the plethora of devices that can render an MPEG2 or MPEG4 stream, I've wondered about making a VNC to MPEG[2|4] over uPnP stream tool - that would allow a device such as a Box Office Patriot to display (though not interact with) a client running a reasonable OS, without modifying the software on the device.
And if the VNC server were able to "see" the drawing instruction stream (e.g. xvnc), then the generation of the MPEG stream could be optimized using that information (e.g. moving a window could just generate the needed MPEG4 motion vectors rather than generating a pixel block update).
Which suggests that for control you'd send back a "picture" of a control dial or a picture of a switch setting.
Handy if you don't have any normal control or monitoring protocol, or perhaps you don't want whose being monitored to know they are being monitored.
Thumbs up for general cleverness.
But I don't know what it's for either.
Biting the hand that feeds IT © 1998–2020