[FFmpeg-devel] [PATCH v2 2/3] avformat/udp: Fix IP_MULTICAST_TTL for BSD compatibility

Marton Balint cus at passwd.hu
Mon Feb 7 00:15:18 EET 2022



On Sun, 6 Feb 2022, lance.lmwang at gmail.com wrote:

> On Sat, Feb 05, 2022 at 01:26:18PM -0800, Chad Fraleigh wrote:
>> Since any [valid] value over 255 is impossible in the IPv4 protocol (the TTL field is only 8-bits), it should always be capped at 255 (for consistency) or return an invalid value error (the one I would suggest).
>>
>
> zhilizhao have submit a patch to limit the range of ttl from option. Do you want
> to return an invalid error here still?

I have applied the patch, so capping is no longer needed.

>
>
>> Despite VLC's reversed comment, using an int seems to be the exception 
>> to the rule (i.e. only linux and windows seem to use it 
>> [as-documented]), perhaps doing the unsigned char first and using the 
>> int as the fallback would be better? It's not really just a BSD thing, 
>> unless you also count LWIP and Solaris as BSD. Unless VLC's code 
>> history shows them doing it this way at one time and swapping it (but 
>> forgetting the comment) to fix a known bug?
>>
>
> I have blamed vlc code and sure the code doing it this way at one time(104938796a3).
> For the mismatch of code and comments, I prefer to code always as code were build
> and used by all kinds of system which vlc is supported already.
>

Yeah, I agree, if we are copying VLC approach then probably it makes more 
sense to use the same order as they do in their code.

Thanks,
Marton


More information about the ffmpeg-devel mailing list