Lacking a better place to debate this, I would like to ask some
questions on a video codec idea...
The goal is basically to create a very fast lossless screen capture
codec (i.e. in the input there will be lots of repeated "colors" of
neighboring pixels, not a lot of dynamic content between frames).
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].
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.
For instance, given 3 frames of video ("one after another" from the
incoming video stream), "combine them" into one stream like:
pixel 1 frame 1, pixel 1 frame 2, pixel 1 frame 3, pixel 2 frame 2,
pixel 2 frame 2, pixel 2 frame 3 ...
then basically apply LZ4 or density algorithm to those bytes.
The theory being that if there is a lot of repeated content between
frames, it will compress well.
The basic need/desire for this was that huffyuv, though super fast at
encoding (it basically zips the frame), seems to create *huge* files,
I assume because "each frame is an I-frame" so it has to re encode
everything each frame. 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) :)
Any feedback on the concept?
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).
Thanks.
-roger-
[1] http://fastcompression.blogspot.com/2011/05/lz4-explained.html
search for "64" it has some kind of concept of a sliding window, or
perhaps that's just the frame API dunno.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
