The framehash muxer can be used to compare the unique hash of each frame to ensure that the result is truly lossless: $ ffmpeg -i input%03d.jpg -f framehash. You can use jpegtran to perform lossless optimization on each frame which may provide significant file size savings: mkdir outputdirįor f in *.jpg do jpegtran -optimize -copy none -perfect -v "$f" > "outputdir/$f" done Note that if you omit -framerate then a default of -framerate 25 will be applied to the input. This occurs in single-pass encoding as well (that's why it uses the motion vectors in the first place, after all).You can simply mux the JPG images to make a video: ffmpeg -framerate 30 -i input%03d.jpg -codec copy output.mkv As such, it is largely dependent on the data before/after the frame, not only on the current one. It always performs frame look ahead/behind to determine better ways to compress the current frame (MJPEG does only do a single frame at a time).
Lastly, unless you have a single-frame video, MPEG4 never really encodes a "single frame" at a time. JPEG compression is largely CPU speed dependent, and doesn't really use any instruction set enhancements (for compatibility/stability, and the fact that it doesn't really help - see the changelog entry for November 16, 2006). Some encoders can use special CPU instructions (SSE/SSE2, MMX, etc.), or use GPU acceleration (I know you probably don't, but I'm just mentioning it).
Why one works faster then the other case really depends on how the encoder was implemented, and on how your particular hardware performs when encoding. The difference is that MPEG4 uses a variety of techniques (motion vector compensation, I/B frames, etc.) to enhance both quality and compression ratio. MPEG4 is a true video codec, whereas MJPEG simply compresses each frame into a separate JPEG image.
The two compression algorithms are completely different in the way they function, and MPEG4 can use GPU acceleration as well.
0 kommentar(er)
