[Interest] MJPEG for HD video (was: libjpeg vs. libjpeg-turbo/mozjpeg)

Matthew Woehlke mw_triad at users.sourceforge.net
Tue May 26 19:02:19 CEST 2015


On 2015-05-26 11:56, Konstantin Tokarev wrote:
> FWIW, MJPEG is by far not the best codec choice for HD video.

That depends on how you quantify "best". It's certainly not the best
compression ratio, but it has significant advantages. First, it's stupid
easy to implement, given the ability to save an image, which Qt gives
us. Second, all frames are I-frames, and stored independently, which
itself is helpful for several reasons:

- Storage is greatly simplified; each frame needs only an independent
bag of bytes.

- Seeking is easy; displaying a particular frame does not need knowledge
of any other frames (unlike with other "traditional" video codecs).

- The system is robust against frame loss; since frames are independent,
loss of a single frame does not affect other nearby frames. There are
also no artifacts from temporal compression.

- Pipeline processing is greatly simplified. The system does not need to
preserve any state between frames in order to decode the input imagery.
To the extent that the processing itself does not depend on state,
processing can be done on multiple frames in parallel.

...and (with libjpeg-turbo, anyway) it's plenty fast enough for 1080P.
Experience dumping nominally-in-memory frames (at only 720P!) into a
pipe with ffmpeg on the other end does not encourage me to believe that
we could encode 1080P @ 30 Hz to e.g. H.264 in real time. There's also
the small matter that MJPEG is not patent encumbered. (Or that using a
"traditional" video codec introduces an additional dependency.)

I'll also point out that we were using *raw* before we added "MJPEG"
support. (This is particularly relevant to the storage and retrieval
points; wrapping the frame in a JPEG container is a fairly minor change.
Retooling to use a "traditional" video codec would be significant work.)

We chose "MJPEG" because it offered a significant size reduction over
raw with very little effort and very little loss of quality. Size is
important to *some* extent, but speed and quality are also important,
and MJPEG gives us a good balance for minimal effort.

-- 
Matthew




More information about the Interest mailing list