[Live-devel] Two client sessions to different servermedia sessions

[saravanan]

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:finlayson at 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/ 

 

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