I warn you, this is a very nerdy post with little practical purpose.
I recently got this idea in my head that I could create a simple video compression algorithm using JPEG compression, but more efficiently than Motion JPEG (MJPEG) which is found on many IP cameras (especially older ones). MJPEG is one of the least efficient encodings ever devised in terms of bandwidth usage. I figured I could improve upon it with relatively little effort, and I was right.
See, MJPEG does not utilize the previous video frame when it is encoding the next one. This is the first and most obvious thing that a video encoding algorithm can do to save space. In most videos, there is relatively little difference from one frame to the next, and if you encode only the changes between frames then you will save space.
So that is what I set out to do. I have an encoding function that works a lot like any other encoding function. You feed it a video frame from your source, and it gives you back a blob of data that the decoding function can convert back into the original video frame (with some quality loss). What my encoding function does is subtract the pixels of the previous frame from the pixels of the new frame and this results in what I call a "diff frame". This diff frame is actually an image that can be compressed as a jpeg image just like any other. Except this diff frame is a relatively low contrast image so it compresses a lot better than the original.
My encoding routine is actually broken right now, but I'm still seeing file size / bandwidth savings of up to about 40% compared to simply recompressing the original frames with the same JPEG compression ratio that I use to compress the "diff frames".
Original frame:
Broken diff frame: (this should be a mostly flat gray image, but something is not working quite right)
If my encoding was working correctly, then a diff frame like that shown above would indicate that all the bright parts of the image got brighter and all the dark parts of an image got darker. A very rare occurrence in the real world...
I suspect if I can figure out what I did wrong and get the diff frames to look the way they are supposed to, then this algorithm would result in space savings closer to 60% if not higher.
I recently got this idea in my head that I could create a simple video compression algorithm using JPEG compression, but more efficiently than Motion JPEG (MJPEG) which is found on many IP cameras (especially older ones). MJPEG is one of the least efficient encodings ever devised in terms of bandwidth usage. I figured I could improve upon it with relatively little effort, and I was right.
See, MJPEG does not utilize the previous video frame when it is encoding the next one. This is the first and most obvious thing that a video encoding algorithm can do to save space. In most videos, there is relatively little difference from one frame to the next, and if you encode only the changes between frames then you will save space.
So that is what I set out to do. I have an encoding function that works a lot like any other encoding function. You feed it a video frame from your source, and it gives you back a blob of data that the decoding function can convert back into the original video frame (with some quality loss). What my encoding function does is subtract the pixels of the previous frame from the pixels of the new frame and this results in what I call a "diff frame". This diff frame is actually an image that can be compressed as a jpeg image just like any other. Except this diff frame is a relatively low contrast image so it compresses a lot better than the original.
My encoding routine is actually broken right now, but I'm still seeing file size / bandwidth savings of up to about 40% compared to simply recompressing the original frames with the same JPEG compression ratio that I use to compress the "diff frames".
Original frame:
Broken diff frame: (this should be a mostly flat gray image, but something is not working quite right)
If my encoding was working correctly, then a diff frame like that shown above would indicate that all the bright parts of the image got brighter and all the dark parts of an image got darker. A very rare occurrence in the real world...
I suspect if I can figure out what I did wrong and get the diff frames to look the way they are supposed to, then this algorithm would result in space savings closer to 60% if not higher.
