2015-10-14 20:08 GMT+02:00 Roger Pack <rogerdpa...@gmail.com>: > I have become aware of some "fast" compression tools like LZO, LZ4, > density, etc. It seems like they all basically compress "the first > 64KB then the next 64KB" or something like that [1].
It's generally the size of a window or dictionary, in which the decoder can refer past strings. There are of course far better dictionary-based methods, the details coming to how much you can predict which strings are going to be useful for a particular part of the image Not exactly like blocks, though, as looking to another image is already farther than a lot of the window sizes used. > My idea is to basically put pixels of the same position, from multiple > frames, "together" in a stream, then apply normal (fast) compression > algorithms to the stream. The hope being that if the pixels are the > "same" between frames (presumed to be so because of not much dynamic > content), the compression will be able to detect the similarity and > compress it well. That's Zip Motion Blocks Video, see zmbv. There's also an encoder. Or equivalent. The fact that in screen content, images are pretty static is rather well known. For natural content too, but with somewhat different handling. > And also the egotistical desire to create the > "fastest video codec in existence" in case the same were useful in > other situations (i.e. use very little cpu--even huffyuv uses quite a > bit of cpu) :) It's also a matter of parallelism and quality of implementation. Otherwise, huffyuv, lagarith, and a lot of lossless codecs (ffv1?) are mostly for natural images (where difference from a pixel to another is small, or smaller than screen content). There's a gsoc project to add inter-frame compression to ffv1 (don't know the status). > Also does anything similar to this already exist? > (though should I > create my new codec, it would be open source of course, which is > already different than many [probably efficient] screen capture codecs > out there). Well, practically, I think it's a dead end. I don't know if screen content encoders were updated to handle multithreading (using slices of images like ffv1 & co), but that might be a start, as speed is a concern to you. Now, there's value for yourself in discovering what all this entails. -- Christophe _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
