MJPEG has hung on for years, still in use in some systems despite H.264's dominance for the better part of the past decade. However, now some manufacturers have removed MJPEG from their cameras and recorders, forcing users to stream H.264.
We look at this issue, products potentially affected, and its impact on applications in this note.
The *****: ***** ******* *******
******* ** *** ***** ***** *** multiple *************, *** ** ******** *********, MJPEG ** ** ****** ** ****** (or ** ****** *******, *** *****).
*** *******, ******* ** *** *** interface ** * ********* ***** ******, H.264 ** *** **** ****** ***** in *** "***** ********" ********, ***** MJPEG *** ********** *****.
*** **** *** **** ** *** current ********* ****** ** *******, ******* from **** ** **. **** ********* any ***** *****.
*********, ** ******* ***** *******, *.*** is *** **** ****** *** *** main *** *** ******, ***** *****. Note **** ***** *** ** **** as * ********* (** * ********** in **** *****, *** *****).
VMS *******
***** **** *** ******* ** *******, MJPEG ** ** ****** ********* ** an ****** **** **** ******* ** VMSes, ******.
*** *******, ******** ***** ******* ** Exacq, ***** ** ** ************* ** not ******* *** *****, **** *.*** (seen ** *** ****** *** ******* below). **** *** **** ** *** Bosch, *********, *** ***** ******* ** checked.
***** ***** ****** ****** *** *** support ***** ** ***** ******* ** had ****** **** ***** *******:
Impact ** ********** ************
*** **** *********** ****** ** *****'* removal ** ** **** ******* ************ which ******* (** ******** ******) ** MJPEG ******. *** *******:
Some ***** ***** *****
**** ** ****, **** ************ ****** bid ************** ***** ******* *****, ******* the ********* *** ******* ********** ** H.264 *** *** ********** ***. ***** responding ** ***** **** ****** ********* **** codec ************, ** ***** ****** ****** may ** ********** ** ****, ** should ******* **** *** *****/********* ** see ** *.*** ***** ** ********.
Note: ***** *** ****** *******
** *** ***** **** ***** **** and *****, ***** **** *** ***** image ******* ********** **** *.***. ** its *******, *.*** ******** **** **** mature *** ***** **** *********** ** how ** **** ********* *** *****, with **** *********** ******** ***** ******* or *********** ********* *** ** **** *-***** *********, ****** ***** * "****" ****** for ****. *******, ***** ****** *** reduced ** ********** ** **** ****** chips *** ****** ********** ** ******* settings, ***** **** ********* **** *********** with *.***.
*** *** ******* ** *.*** ***** *******? *** *.*** ** ***** - ******* *** Bandwidth ****** *** **** *******.
Vote - ****
I wonder if they are no longer supporting an MJPEG stream at all, or if they are just removing it from the web interface as a configuration option.
Maybe MJPEG is still available via. OID or API commands (i.e. for those specialized applications), but they simply don't' expose MJPEG to the user.
I see no real reason to not allow it at all, but I can understand now allowing a standard user to configure it. 'Save them from themselves' mentality?
I agree with you, it quite likely is available via API. Especially considering most web interfaces default to MJPEG for live video display. It's just not an option when connecting with VMSes increasingly often.
Many VMS mobile or web clients can only use MJPEG streams. If an H.264 is the only available stream it needs to be transcoded using CPU resources. If you can send it MJPEG it passes right through. I say keep it!
I believe MJPEG streaming is required by ONVIF Profile S. So...
From the ONVIF mandatory features of Profile S
So either all Hik's cameras are no longer Profile S compliant or MJPEG is still there as an option thru ONVIF.
Well...start filling in the nonconformance form (joking, mostly).
I pulled up a Hikvision 2042 in ONVIF DM, no option for JPEG here:
It's not shown as an option in Profiles, either.
I added it to Exacq via ONVIF, as well, no MJPEG.
Interesting. I wonder how these cameras pass the test tool?
btw, here's the table of contents page for profile S. It shows how MJPEG is treated as mandatory, although h.264 and MPEG4 are not.
I'll take a look at the test results for the 2042. Maybe ONVIF could clarify?
i get tired of trying to jack with MJPEG to get it to work on home automation systems. I think HA systems should adopt h.264 decoding instead.
What's the benefit of dropping it? I can't think of a time I have had to set a camera to MJPEG other than when a sales person underspecified processors on a server. Does it save development time or related costs in any way? If it does I would not mind it disappearing.
After 49 votes, opinions are fairly evenly split about drop vs. keep. 53% keep, 47% drop. I expected things to be more lopsided in one direction or the other.
Interestingly, integrators are more prone to drop; manufacturers are more prone to keep.
This is likely a little push to use H.264. This is not MJPEG drop.
MJPEG encoder is so cheap at the moment that it does not make any impact on hardware price. MJPEG encoder is part of any chip. On another hand it's not about ONVIF, MJPEG is still standard for browsers. Camera/device manufacturer still need to make browser UI wich natively works everywhere. We still need still images. And we still need a way to get those from the camera.
Ethan, have you tried any of the old url's directly, like cgi-bin/video.jpg etc?
Unfortunately, all MPEG compression protocols are subject to aliasing and artifact. Much of my projects are in manufacturing for process control and machine monitoring. We must use MJPEG to monitor machines in motion or there is blur that defeats to purpose of the camera. We installed a number of cameras in a stamping press of a major auto manufacturing plant to catch defects being made and determine the cause using frame by frame analysis. This wouldn't work with any compression and we had to use MJPEG.
...determine the cause using frame by frame analysis. This wouldn't work with any compression and we had to use MJPEG
Try setting the GOP ratio to 1 or all I-frames, if possible.
All frames will be complete frames just like MJPEG, but the file size is still likely to be half, due to the better static image compression algorithims.
My concern when testing. If I use MJPEG instead of the fancy , H264, H264+, H265, H'whatever coding I have less impact on the image quality. So first I always test MJPEG streams, then the H264, etc. With this I can see the real IQ, and the effect of compressions used. So different manufacturers can be compared better on videoIQ
