[Live-devel] How about HD streaming?

[Ross Finlayson]

>the streaming server application was testMPEG1or2VideoStreamer. On the 
>receiver side (rmem_maxsize = 64k) we tested three scenarios
>
>- scenario 1: a small test application which reads from the socket and 
>prints out the sequence numer of the RTP-packet and its size
>- scenario 2: an actual mplayer compiled with the actual liveMedia version 
>with the same debug messages mentioned above
>- scenario 3: testMPEG1or2VideoReceiver piped to mplayer also with the 
>debug messages
>
>The debug messages are also included on the server side so you can check 
>the differences with diff. So you can see which packets have been received 
>and have they been received completely.
>
>For streaming I used three MPEG2 files, a 5.5 Mbps from a DVD, a 9 Mbps 
>and a 50 Mbps both recorded by a IVTV card.
>
>scenario 1:
>5,5 Mbps: 241116 packets sent, 23 lost => 0% loss
>9 Mbps: 176203 packets sent, 158 lost => 0,09% loss
>50 Mbps: 90680 packets sent, 1917 lost => 2,11% loss
>
>scenario 2:
>5,5 Mbps: 613219 packets sent, 8842 lost => 1,44% loss
>9 Mbps: 168987 packets sent, 8749 lost => 5,18% loss
>50 Mbps: 203513 packets sent, 59621 lost => 29,30% loss
>
>scenario 3:
>5,5 Mbps: 188852 packets sent, 15087 lost => 7,99% loss

What happens if you increase the kernel's input socket buffer size to a 
(much) larger value (e.g., 1 MByte)?

>So you can see there are some problems in the network code.

Well, I still maintain that the major 'problem' is the default size of the 
Linux kernel's socket buffer.  I think that any receiver that does anything 
non-trivial with the input data (e.g., writing it to a file or pipe - not 
just your "scenario 1") is going to have problems with a socket buffer size 
this small.  However, I'm willing to concede that perhaps the LIVE.COM 
could be improved to mitigate the effects of this problem.

>How can we help you to debug this problem? Perhaps we can solve this 
>problem together.

I don't have time to look into this right now, but let me know whatever you 
find.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>