Figure 1: The S8600 has an enormous built-in zoom lens.
The fact that some software can act as an NLE editor for video is sometimes a by-product of animation facilities. The frame-by-frame JPEG image file format of motion-jpeg – which uses the MJPEG acronym – makes it automatically a candidate for any kind of animation software action, in the same way gifs and apngs are animated. MJPEG is just a series of JPEG picture images inserted serially into a file. MJPEG is all I need, so I don’t care about any other codecs (whether they exist or not). It’s beautiful in its simplicity, although it does have some drawbacks.
All video consists of frames of course, but the JPEG images in a MJPEG video file are just that – individual images – which can be cut out and deposited into a directory, which would then of course contain possibly many hundreds or thousands of individual picture images. Most video formats do not operate that way. Some may instead rely on the differences between one frame and the next, where the individual frames are reconstructed with complicated decompression software that takes the form of proprietary or non-proprietary codecs. Some video formats and their associated codecs simply intelligently compress the raw video as it happens.
So, the MJPEG format doesn’t really require a codec in the usual sense, and its IP history is entirely based on the JPEG image format itself. By today, that format is able to be used unencumbered (IANAL – so don’t take this as advice).
The MJPEG video is generally of pretty good quality too – thanks to the dynamic range of the JPEG image format. So, you ask, why do people ever use anything else? Good question. There’s always a trade-off when comparing things like this. The trade-off for having a pretty good quality MJPEG+PCM AVI encapsulated video, which can be decompressed very rapidly without any codecs (other than image libraries) – versus a similar quality compressed video (say vpx/webm for instance) – is that JPEG doesn’t compress as much. In other words, the videos are a lot bigger, size wise. As an example, the size of my Hutch video (used in the edit session) is 1.1 Gigabytes. As a compressed file, it could be as small as 100 Megabytes (and still have reasonable quality).
Why do we need small video files? We don’t, necessarily. It depends on your usage of the video. If it needs to stream over the internet, then MJPEG is almost impossible because a 1.1 Gigabyte MJPEG file must be streamed at a very high network speed in order to be playable on the client end, in real time.
But heck, I usually don’t stream anything over the internet, and just play it from the hard drive, or SSD. And – since my drives are pretty big, I don’t worry too much about the disk space used.
I sometimes use YouTube, and often I upload my videos as “MJPEG + PCM” AVI container files. I.E, I upload a single “AVI” container file that contains both a PCM audio stream and also an MJPEG video stream. The S8600 actually outputs AVI container files, containing both the audio and video streams, to the uSD memory card. Most similar cameras do this as well. It sounds contradictory, but the reason it works is that Google compresses my MJPEG+PCM=AVI file into something that can be reasonably streamed, like vp8/webm, vp9/webm, or mp4.
Some cameras use the combination of an H264 or H265 video stream, and AC3 audio stream, and put both of those inside an “MP4” container file. Those require a proprietary codec to edit or play.
Note: The S8600 is a product of the Fujifilm Corporation and Fujifilm Holdings Corporation, and is not connected with this author and site in any way. FujiFilm is their trademark, as well. The Panasonic cameras listed on the page are a product of Panasonic Corp, which owns all respective trademarks. The Cannon cameras listed are a product of Canon Inc, which owns respective trademarks. Nikon cameras are product of Nikon Corporation, and they hold respective trademarks. This site and author is not affiliated with any of these companies.