<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Mac OS X - Multicast UDP not working?</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=2>Cool! I did some snooping around here trying to find out why we have some encoders spitting out quite large UDP packets, but I haven't really been able to come to any conclusion other than it was because our QA was testing the encoders with lots of different values, and apparently some legacy (older) decoders expected larger UDP packet sizes.</FONT></P>
<P><FONT SIZE=2>I agree that having UDP packets split across ethernet frames is not the most efficient way of transmitting data, but its looks like there are encoders out there (like ours and v-brick) which allow this option. Anyway, thanks for adding the option to VLC.</FONT></P>
<P><FONT SIZE=2>-johnny</FONT>
</P>
<P><FONT SIZE=2>> -----Original Message-----</FONT>
<BR><FONT SIZE=2>> From: Christophe Massiot [<A HREF="mailto:massiot@via.ecp.fr">mailto:massiot@via.ecp.fr</A>]</FONT>
<BR><FONT SIZE=2>> Sent: Friday, July 19, 2002 2:30 PM</FONT>
<BR><FONT SIZE=2>> To: vlc@videolan.org</FONT>
<BR><FONT SIZE=2>> Subject: RE: Mac OS X - Multicast UDP not working?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> At 14:27 -0400 19/07/2002, Talbert, Scott wrote :</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> >I don't know why exactly VLC expects UDP packets to be < 1500 </FONT>
<BR><FONT SIZE=2>> >bytes. I suggested (to Christophe, on the VLC team) that they be </FONT>
<BR><FONT SIZE=2>> >able to handle packets up to 64K in size (the UDP limit) but he has </FONT>
<BR><FONT SIZE=2>> >not responded yet.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> VLC expects UDP packets to be < 1500, because I don't see the point </FONT>
<BR><FONT SIZE=2>> in sending bigger packets on Ethernet networks. It will just increase </FONT>
<BR><FONT SIZE=2>> fragmentation for no gain. But anyway since people are actually doing </FONT>
<BR><FONT SIZE=2>> it, we'll have to find a solution.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> I needed some thinking and I finally decided not to follow your </FONT>
<BR><FONT SIZE=2>> advice. The reason I'm skeptical is because as per the VLC structure, </FONT>
<BR><FONT SIZE=2>> packets are always allocated with DEFAULT_MTU size. But if the server </FONT>
<BR><FONT SIZE=2>> sends 1500-bytes packets, we lose 65536-1500 = 64036 bytes. There can </FONT>
<BR><FONT SIZE=2>> be thousands of packets in the decoder buffers, so we would explode </FONT>
<BR><FONT SIZE=2>> our current (quite low) memory requirements. A workaround would be to </FONT>
<BR><FONT SIZE=2>> memcpy the big network buffer to a buffer allocated with the right </FONT>
<BR><FONT SIZE=2>> size, but it has always been against our policy to add unnecessary </FONT>
<BR><FONT SIZE=2>> memcpy()s, for obvious performance reasons.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> So what I have done is add a --mtu option. By default it is still </FONT>
<BR><FONT SIZE=2>> 1500 bytes, but you can change this value without recompiling. This </FONT>
<BR><FONT SIZE=2>> option should be added to the GUI Preferences windows, so that it can </FONT>
<BR><FONT SIZE=2>> be changed permanently.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -- </FONT>
<BR><FONT SIZE=2>> Christophe Massiot.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -- </FONT>
<BR><FONT SIZE=2>> This is the vlc mailing-list, see <A HREF="http://www.videolan.org/vlc/" TARGET="_blank">http://www.videolan.org/vlc/</A></FONT>
<BR><FONT SIZE=2>> To unsubscribe, please read <A HREF="http://www.videolan.org/lists.html" TARGET="_blank">http://www.videolan.org/lists.html</A></FONT>
<BR><FONT SIZE=2>> If you are in trouble, please contact <postmaster@videolan.org></FONT>
<BR><FONT SIZE=2>> </FONT>
</P>
</BODY>
</HTML>