Problem MJEG stream with proxyserver

[임차섭]

_______________________________________________
live-devel mailing list
live-***@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel

[Ross Finlayson]

When I test h.264 via live555ProxyServer, It's works, but MJEG stream is broken(Loading Image... <https://dl.dropboxusercontent.com/u/4188226/mjpeg_broken.png>).
RTSP Client is VLC and back-end RTSP Server is IP-Camera.
I am using lastest version.

Including the latest version of VLC: 2.1.5 ?

please help me.

Sorry, but VLC is not our software. You should use our “openRTSP” client application for your initial testing: http://live555 <http://live555/>.com/openRTSP/

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

[=?ks_c_5601-1987?B?wNPC97y3?=]

Hi.



I tested openrtsp, but result is same. Jpg image is broken. Image file is
created by ¡®-m¡¯ option of openrtsp.



Thank you.

[Ross Finlayson]

Post by =?ks_c_5601-1987?B?wNPC97y3?=
I tested openrtsp, but result is same. Jpg image is broken.

Congratulations! You’ve just discovered why MJPEG streaming - especially with very large frames - is a terrible idea. As I note in the FAQ:

"You should be aware, though, that JPEG is a very poor codec for video streaming, because (unlike MPEG, H.264 or H.265 video) there is no inter-frame compression. Every video frame is a 'key' frame, and is sent in its entirety. Also, each frame is typically large (and so takes up many network packets). If any of these network packets gets lost, then the whole frame must be discarded. JPEG video streaming is strongly discouraged, and should be considered (if at all) only for high-bitrate local-area networks with very low packet loss.”

What you’re seeing is packet loss. Because you have doubled the number of network interfaces in your system (in addition to the transmitter’s and the receiver’s interface, you now have the input and output interfaces of the proxy) you have at least doubled the packet loss rate, which *vastly* decreases the likelihood that a complete JPEG frame will be passed end-to-end.

Your only real solution is to stop trying to stream MJPEG. Instead, transcode to H.264, and stream that.

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

[=?ks_c_5601-1987?B?wNPC97y3?=]

Hi.



Thank you for reply.



I found that fFrameSize is 1444 in
PresentationTimeSubsessionNormalizer::afterGettingFrame
(ProxyServerMediaSession.cpp).

This value occurred fOutBuf->wouldOverflow because fMax of fOutFuf is 1448(
rtp header(12) + 1444 > fMax(1448)).

So I changed fMax value by calling setPacketSizes(1000, 1456) in
MultiFramedRTPSink constructor.

It is works fine. But I don¡¯t know how to correct fix code in my case.



Would you help me?



Thank you.

[Ross Finlayson]

Aha! Yes, you found the problem (which was different from what I had originally thought): Your input JPEG/RTP packets were unusually large (1456 bytes, plus IP, UDP headers). Because of the special way that we proxy JPEG/RTP packets, this turned out to be a problem for us.

I’ve now installed a new version (2014.10.21) of the “LIVE555 Streaming Media” code that increases the maximum output RTP packet size from 1448 to 1456 (as you did).


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