<html><head></head><body>Of course varying sizes happen.<br><br>And we cannot wreck the performance of sane usage (1500 bytes or less) just to support insane usage. Allocating 64 KiB block probably requires between 68 and 128 KiB of heap depending on implementation; it is *not* suitable for receiving 1500 bytes packets.<br><br><div class="gmail_quote">Le 18 octobre 2018 00:11:50 GMT+03:00, Ilkka Ollakka <ileoo@videolan.org> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Wed, Oct 17, 2018 at 07:05:25PM +0300, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Le tiistaina 16. lokakuuta 2018, 21.16.19 EEST Ilkka Ollakka a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">In this approach, mtu is setted to high on start, and if received data<br>is less than 1500 and mtu is higher than that, we adjust mtu on future<br>packets to be smaller. In majority of cases in UDP streaming, packet<br>size is usually quite constant, so it should work, even if it's not<br>generic solution to udp packet receiving.<br></blockquote></blockquote><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">I don't think we can shrink the receive buffer on the basis of a single <br>packet, or really any number of packets.<br></blockquote><br>In theory it's possible that packet sizes vary hugely. But in practise,<br>what I have seen, they are most likely below 1500 or way above 1500. Or<br>have you seen different style of streams in plain udp streams?<br><br>If we don't leave the assumption aside that vlc udp access should be<br>able to handle all kind of udp traffic, then the approach and<br>performance penalties needs to be taken, but if we can make assumption<br>that vlc udp access is intended for media receiving, then why couldn't<br>we assume things on stream?<br><br>And anyway if it gets truncated, there is a code to increase the size<br>later on.<br><br>Ofcourse you can take the approach to do the MSG_PEEK to get perfect<br>size for every receive, but most likely that would have already been<br>taken if there weren't cost for that approach as well?<br><br>Or you can take huge buffer just in case, and pass that around. But that<br>approach had it's own issues.<br><br>Or, like you said, big buffer and memcpy needed parts. But thats also<br>hasn't happened and doesn't really help on performance side.<br><br>I know the proposed approach is not perfect, but I haven't yet hear any<br>real world examples why it wouldn't work.<br><br>If people don't like the approach, it's ok to say it like that, no need<br>to try make up corner cases that aren't really happening or other<br>excuses. Just plain 'I don't like it' and we can all focus the time to<br>something else.<br></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>