Hi Ross,
The issue is not just for MJPEG video. I tried to stream H264(640x480) in "live0" serverMediaSession, and MP4V(640x480) in "live1" serverMediaSession. But the result is same as MJPEG streaming. Below are my environment and observation, Environment : . I am using OnDemandServerMediaSession and created "live0" and "live1" serverMediasessions . I am capturing the video from the device, hence I am setting the fPresentationTime based on the encoder data. And the fDurationInMicroseconds to zero. Observation : . I enabled the flag "reuseFirstSource", so I could play any number of sessions to live0 or live1 without any issues. I could get 25fps. Noticed ~1500kbps bitrate in each client session. . But if I try to play live0 and live1 simultaneously, the streaming frame rate is reduced to 1 or 2 frames. Noticed only ~20kbps!!! . Also noticed that there is no frame loss at client side, but there is no data from the Live555 server !!! Any suggestion from your side will be helpful. Regards, Saravanan S From: Ross Finlayson [mailto:finlay...@live555.com] Sent: Saturday, February 02, 2013 12:45 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Two client sessions to different servermedia sessions I am using OnDemandServerMediaSession and added two servermedia sessions with the name "live0" and "live1". Both serverMediaSessions will stream MJPG video data. I have set the reuseFirstSource flag, so that more than one client sessions to the same serverMediaSession(for e.g "live0") will be served with the single source, that is working fine and I could get 25 fps per session. But when I try to play two different client sessions to "live0" and "live1" then the I could get 3-5 frames per second in the client side!!! MJPEG streams tend to be extremely high bitrate. Wastefully so - which is why, in 2013, nobody should be sending MJPEG anymore! (See <http://www.live555.com/liveMedia/faq.html#jpeg-streaming>) You are probably approaching the capacity of your network, increasing the frequency of lost packets (which *significantly* increases the frequency of lost MJPEG frames!). To help understand this - suppose, for example, that each MJPEG frame is 50 kBytes, and therefore consists of about 35 consecutive RTP packets. Note that if *any* of these 35 RTP packets gets lost, then the receiver will lose (and therefore drop) the *entire* MJPEG frame. Suppose that the packet loss rate is 1% - i.e., assume (for this example) a random loss rate of 1/100. Then, the probability that a (35-packet) MJPEG frame will be received correctly at the receiver's end is (99/100)^35 = 0.70 (approx). I.e., a 1% packet loss rate produces a 30% frame loss rate! Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
