dd optimisation about restream HOT 5 CLOSED

Please go ahead and experiment with this. There is already an issue (#14) where we are discussing possible improvements, so please join us there with your findings.

from restream.

What do you mean with 'sampling the framebuffer'? Do you want to make the compression lossy? Or throw away the unneeded color information?

from restream.

I pulled the framebuffer to a file last night and played with dd trying to selectively grab parts of the file. with a bs of 1 it took about 8 seconds to grab the file so my idea for using seek and skip won't work. Currently it is grabbed in one go i can see, and with the code i got a 5mb image. Photoshop can open if you help it out and it is indeed the screen.
But yeah, throw away the colour information was my late night idea!

from restream.

We also read the first 1408 * 1872 * 2 bytes (width * height * 2 byte per pixel), there are a lot null bytes after that.

You could try researching the difference between the two color schemes (grey16le and rgb565le). If we can just throw away every other byte for example that would be great!

I'm a bit hesitant in writing custom binaries for this because that would complicate the setup further.

from restream.

I'm with you on the binaries.

I also, when not specifying certain parameters, got what looked like a blank screen worth of null bytes.

I'm thinking le is lower endian? so we have 16 bits to encode the grayscale. I was thinking could we not drop some info here, 1bit monochromatic. We could still pop it through gzip afterwards, though as the page builds up we would have diminishing returns on that.

from restream.