[FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection

[Ignjatović, Lazar (RS)]

> Your MR makes even less sense for multicast. For multicast there is no local address to match to an interface. So you just have to have the interface specified explicitly in addition to the LL group address. This is true for both egress and ingress.

I've compared ffmpeg 5.1.2 against my MR on IPv6 multicast. Here are the results:

Recv (on interface other than default)

|     Address    |     localaddr     | 5.1.2 | MR  |
| -------------- | ----------------- | ----- | --- |
| FF11::1        | null              | NO    | NO  |
| FF11::1        | iface addr        | NO    | YES |
| FF11::1%eth0   | null              | NO    | YES |
| FF12::1        | null              | NO    | NO  |
| FF12::1        | iface addr        | NO    | YES |
| FF12::1%eth0   | null              | NO    | YES |
| FF14::1        | null              | NO    | NO  |
| FF14::1        | iface addr        | NO    | YES |
| FF14::1%eth0   | null              | NO    | NO  |
| FF15::1        | null              | NO    | NO  |
| FF15::1        | iface addr        | NO    | YES |
| FF15::1%eth0   | null              | NO    | NO  |
| FF18::1        | null              | NO    | NO  |
| FF18::1        | iface addr        | NO    | YES |
| FF18::1%eth0   | null              | NO    | NO  |

Send (on interface other than default)

|     Address    |     localaddr     | 5.1.2 | MR  |
| -------------- | ----------------- | ----- | --- |
| FF11::1        | null              | NO    | NO  |
| FF11::1        | iface addr        | NO    | YES |
| FF11::1%eth0   | null              | YES   | YES |
| FF12::1        | null              | NO    | NO  |
| FF12::1        | iface addr        | NO    | YES |
| FF12::1%eth0   | null              | YES   | YES |
| FF14::1        | null              | NO    | NO  |
| FF14::1        | iface addr        | NO    | YES |
| FF14::1%eth0   | null              | NO    | NO  |
| FF15::1        | null              | NO    | NO  |
| FF15::1        | iface addr        | NO    | YES |
| FF15::1%eth0   | null              | NO    | NO  |
| FF18::1        | null              | NO    | NO  |
| FF18::1        | iface addr        | NO    | YES |
| FF18::1%eth0   | null              | NO    | NO  |

Here are the reasons why the combinations marked NO under my MR don’t work:

FF11::1      -> ambiguous interface on which to listen/send
FF12::1      -> ambiguous interface on which to listen/send
FF14::1      -> ambiguous interface on which to listen/send, uses only default iface
FF14::1%eth0 -> getaddrinfo errors as it supports %scope only for link-local
FF15::1      -> ambiguous interface on which to listen/send, uses only default iface
FF15::1%eth0 -> getaddrinfo errors as it supports %scope only for link-local
FF18::1      -> ambiguous interface on which to listen/send, uses only default iface
FF18::1%eth0 -> getaddrinfo errors as it supports %scope only for link-local

So the problem to overcome here is controlling on which interface we listen/send multicat IPv6.
For link local yes, %scope is the way to go.

I proposed this MR as the solution to the problem, keepeng the `localaddr` parameter semantics the same as with IPv4.

Other solution could be introduction of a new parameter, as I said before. In this case then, the documentation should
be changed to reflect that `localaddr` is only used for IPv4 addresses, and that same functionality can be obtained with
this new parameter under IPv6.

There will certainly be V3 of the patch, as I've identified minor changes needed for this approach.
If you have any other ideas, I'm open to hearing them.

Lazar Ignjatović
Associate Software Engineer

Cubic Defense
cubic.com

This message has been marked as Public on 03/21/2024 13:01Z.