[vlc-devel] [PATCH] Add support for AMT

[Nick Briggs]

> Date: Wed, 25 Sep 2019 07:35:24 +0300
> From: Rémi Denis-Courmont <remi at remlab.net>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] [PATCH] Add support for AMT
> Message-ID: <11800838.hKLCE3pLEh at basile.remlab.net>
> 
> Le keskiviikkona 25. syyskuuta 2019, 6.25.11 EEST Natalie Landsberg a écrit :
>> Updated amt.c with all changes made in this branch:
>> https://code.videolan.org/tguillem/vlc/commits/amt/8
>> 
>> This should address the majority of comments from last submission.
>> Primarily cleaning up the code with Thomas' help to better fit VLC's code
>> style.
>> 
>> One note:
>> recvmsg() had to be used in BlockUDP() instead of recv() because VLC crashes
>> otherwise. udp.c uses recvmsg() as well.
> 
> No, udp.c does not use recvmsg() because of "crashes".
> 
> udp.c uses recvmsg() because it needs vectorised I/O, and send/sendto don't do 
> vectorised I/O. And that vectorised I/O is a work-around for broken unicast 
> senders not respecting the MTU.

I agree it's not because of "crashes".

udp.c was written that way because it's the only way that works for all the supported OSes such that you can receive packets up to the 64K maximum datagram size, without truncated data, without having to allocate 64K for every receive buffer. 

Linux recv/recvfrom has the MSG_TRUNC flag to return the untruncated datagram size, macOS does not support that.

In at least one version of the udp.c code there was a lot of conditional compilation based on the presence of MSG_TRUNC, but it always ended up having to note the truncation, report it upstream, and attempt to compensate by increasing the buffer size either by a (as you put it...) cargo-cult sizing algorithm or based on the size of the last truncated datagram.

> 
> I don't see why that work-around would be needed for AMT, which most likely 
> does not have to deal with the same craptastic unicast servers that udp.c has 
> to, and thus can dispense with all that cargo-culting from udp.c.
> 
> 
> Also, using vlc_timer would be simpler than an ad-hoc thread here, still.
> 
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
>