[Live-devel] Unable to proxy mjpeg with live555ProxyServer

Sat Mar 30 07:42:09 PDT 2013

Hi Ross,

just as a side note (and because this is not the first time you are saying this), your last sentence about that nobody should be streaming MJPEG in 2013 is wrong. Well, despite my e-mail address, I am not a casual hobbyist :), but since there is a little to none protection in mail lists in general against spammers collecting addresses from such lists, we typically do not use our company's domain names for mail lists.

Please understand that in our industry (video surveillance software solutions) MJPEG is still widely used, in fact there are numerous reasons for using MJPEG in security industry, such as

- security operators often need to view a high number of cameras at once in their applications at higher frame rates, which can be done with much less CPU power when using MJPEG. Decoding H264 is much more CPU intensive and when security cameras are installed in local networks, where bandwidth is not an issue, MJPEG is the better choice here,

- many video analytics applications often prefer MJPEG over H264 video as the input, because such applications are CPU intensive and often reduce the load by not decoding the entire stream but just some of the frames which can be done better with MJPEG because of no interframe compression,

- mobile platforms have certain limitations regarding H264 - even with the latest Android (Jelly Bean) and the new Google's Media Codec API you cannot effectively display more H264 streams at once. To give the security operator a chance to view 4 or 9 cameras in his device (what he really needs to), MJPEG (with limited resolution) is again the better choice than H264.

And there are other reasons. So please understand that the bandwidth (or frame size) is not the only factor making a given codec better than another one, as this is application specific. Of course, if there is a limited bandwidth and one needs full frame rate video, H264 will be the ideal choice with no chance for MJPEG to compete here because of the large frame sizes.

Please note, that all technological leaders in the IP camera world (like Axis, Bosch, Sony, Samsung, Panasonic, Brickcom, Vivotek, IQinVision and many others) are still adding (and will continue to add) MJPEG to their IP cameras (even in 2013 models :), so, as you can see, I am standing not alone here :). They are doing it for a reason.

Last but not least, according to ONVIF for example, an IP camera MUST support MJPEG, a QVGA MJPEG stream is mandatory for every ONVIF compliant model for better interoperability and flexibility. So it seems that supporting MJPEG in Live555 is still a good idea, even in 2013 ;).

Have a nice day.

Alex

______________________________________________________________
> Od: "Ross Finlayson" <finlayson at live555.com>
> Komu: "LIVE555 Streaming Media - development & use" <live-devel at ns.live555.com>
> Datum: 30.03.2013 01:25
> Předmět: Re: [Live-devel] Unable to proxy mjpeg with live555ProxyServer
>
I have an IP camera that gives MJPEG over RTSP, I'm trying to proxy the stream with:$ live555ProxyServer rtsp://192.168.0.221/live2.sdp <http://192.168.0.221/live2.sdp>When I use the openRTSP client like so:$ ./openRTSP rtsp://127.0.0.1:10110/proxyStream <http://127.0.0.1:10110/proxyStream>The output looks like this: http://pastie.org/7167135 <http://pastie.org/7167135>What happens when you try running "openRTSP" directly on the IP camera stream (i.e., without using a proxy server in the middle)?What happens when you try viewing the stream using VLC - both directly from the IP camera, and indirectly, through the proxy?I suspect that your problem is network packet loss - which is often a problem when streaming a low-efficiency codec such as JPEG.  JPEG frames are usually *huge*, and each JPEG frame gets packed into many (often dozens!) of RTP packets.  If even one of these RTP packets gets lost, the entire JPEG frame will get discarded by the receiver.This situation is worse
  if you have a proxy server in the middle, because it means that - for a complete JPEG frame to make it end-to-end from the IP camera to your receiving client - there must be no packet loss either on the camera->proxy link, or in the proxy->client link.Your best solution (especially as appears to be just a hobby for you) is to use a better IP camera - one that streams using a better codec (such as H.264).  (In 2013, nobody should be streaming MJPEG anymore.)

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ <http://www.live555.com/>

----------

_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel <http://lists.live555.com/mailman/listinfo/live-devel>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130330/a0e10892/attachment.html>