[Live-devel] streaming tests

[Florian Winter]

hi

we have done some tests with MPEG 1/2 streaming with libliveMedia's 
test1or2MPEGAudioVideoStreamer application. the goal was to test what 
video bitrates can be handled by libliveMedia without data loss, and 
whether MPEG 1/2 audio/video streaming works correctly. unfortunately 
the results were not quite satisfying: for correctly receiving a stream 
with more than approximately 3 MBit/s, we needed to make adjustments to 
the receiver's network configuration. also we had problems receiving 
MPEG audio and video using one instance of mplayer.


 * Configuration

as input files, we used MPEG1 and MPEG2 program stream files (containing 
MPEG audio and video) that were generated by a Hauppauge WinTV PVR 350 
card with different bitrates. We also used some other files (not 
generated by the Hauppauge card) to make sure that problems we found are 
not limited to MPEG streams from the TV card.

as a receiver we used either libliveMedia's test1or2VideoReceiver 
application (for video only) and mplayer, using the provided SDP files 
testMPEG1or2AudioVideo.sdp and testMPEG1or2Video.sdp.

as hardare we used two fast linux PCs (fast = dual 1 GHz CPUs) and 100 
MBit LAN.


 * Results

with video only (testMPEG1or2VideoReceiver and mplayer 
sdp://testMPEG1or2Video.sdp), the results are as follows:
with video bitrates below approximately 3 MBit/s, the video quality is 
flawless. there are no broken frames or artifacts. if the video bitrate 
is 3 MBit/s or greater, the video quality is very bad with lots of 
artifacts and missing frames. this problem can be fixed by increasing 
the RTP socket's receive buffer size to 2MB (default is 64kb). then 
streaming video with 9 MBit/s is no problem (we didn't test with any 
higher bitrates). mplayer seems to make this adjustment as well. if we 
set /proc/sys/net/core/rmem_max to 2MB, mplayer can display the stream 
without artifacts or broken frames. if the maximum receive buffer size 
is 64kb, neither mplayer nor libliveMedia's test application can handle 
the stream.

we then tried to repeat our tests with audio and video, using mplayer 
sdp://testMPEG1or2AudioVideo.sdp. since libliveMedia has no MPEG mux, we 
could only use mplayer for testing. unfortunately it didn't work at all. 
the audio was okay, but the video was displayed with approximately 1 fps 
for a few seconds. then mplayer either crashed or started displaying two 
subsequent frames repeatedly. the timing output of mplayer was strange, too:

A:   4.4 V:   0.0 A-V:  4.444 ct:  0.069   19/ 19   5%  6% 747.9% 18 0 0%

as you can see, the video time is always zero, and the audio-video skew 
equals the audio time. if we run mplayer with the -framedrop option, no 
video frames are displayed at all.

we used a recent and an older build of mplayer and mpeg files from 
different sources (including, but not limited to, the Hauppauge card) to 
reproduce the problem. we believe that it can be reproduced with any 
MPEG1/2 program stream file containing MPEG audio and video. at least it 
was reproducible with all the files we have.
we used the most recent version of libliveMedia for our tests.

 * Conclusion

3MBit/s is only a small fraction of the bandwidth of our LAN, and that a 
system with two GHz CPUs should be able to handle much higher 
bandwidths. so we assume that the problem is related to the way 
libliveMedia (and mplayer, which afaik is based on the same code) 
schedules reads from the network. data is not read fast enough from the 
UDP socket and thus is overwritten, causing data loss at the receiver. 
increasing the size of the socket's receive buffer seems to fix the problem.

i admit that 3 MBit/s is not a typical bitrate for streaming. however 
consider streaming a VOB stream from DVD (with bitrates up to 9 MBit/s) 
in an 100 MBit LAN. this is certainly a meaningful application, and both 
libliveMedia and mplayer can't handle it, if used as receiver, unless 
adjustments are made to the network configuration of the machine (see 
above).

mplayer seems to have problems with audio/video synchronization. it is 
not clear (to us) whether mplayer or the sender side is at fault. we 
have not done any tests with alternative streaming clients yet (such as 
VLC). however using our own architecture which used libliveMedia for RTP 
streaming, we have similiar timing problems.