Multicast URL launch from browser stopped working

[tangent]

We've got a web app that lets you click on an icon to launch a URL of the form "udp://@239.255.1.2:3456" to view that stream in VLC. As part of setting up each PC, we associate the udp URL scheme with VLC for this purpose.

This has been working for us for years and years, clear back to the days when the browser plugins stopped working. This external launch of VLC is our workaround for the loss of in-browser playback of these streams.

Quite recently, this stopped working on Chrome and Firefox, but not Edge, and we can't see why. These browsers still launch VLC, and inspecting the command line with Process Explorer shows it was called correctly, but all we get is the Playlist window with the URL we passed showing, minus the @ sign, which VLC requires but strips from UI displays for whatever reason. No video plays.

The thing is, if we hit Ctrl-N and put the same URL in, it works, even if we don't relaunch VLC. This suggests the culprit isn't some type of OS security thing like EXE sandboxing, since if that were the case, networking would remain blocked until you restarted the process, no?

One path that does still work is saying "start udp://@239.255.1.2:3456" from cmd.exe, as does pasting the URL into the Windows Run box. (Win-R)

Given that Microsoft-specific paths work (cmd.exe, Win-R, Edge) and everything else fails, we're thinking this is some recent Windows 11 update that broke things, but we can't prove it.

We haven't yet had a chance to try on other platforms to prove our current hypothesis that this is a Windows-specific issue.

Everything is up-to-date: Windows itself, the browsers, and VLC.

[lysek]

We also have this issue, it is a FF/Chrome related problem.

I opened a bugzilla issue and there is a solution: https://bugzilla.mozilla.org/show_bug.cgi?id=1949195

Fill `udp` into `network.url.simple_uri_unknown_schemes` in `about:config`.

[tangent]

Thank you for reporting this.

Given that a request to deploy an updated version of VLC is far more likely to occur than a custom browser settings adjustment, I will repeat a very old request: make the "@" optional in VLC's udp:// scheme URL parser. The current nonstandard usage here is tripping us up to no useful end. If there is no @ sign, parse the URL as if it was given between the second slash and first address character.

I was once told what this @ sign is for, and I no longer recall the reason, but I do recall thinking it sounded like a very narrow niche use case. If the argument to the left of the "@" is rarely needed, the @ sign should be optional, required only in the rare cases where it's meaningful.

[Rémi Denis-Courmont]

@ is part of the URL standard, and you're free not to use it if your use case doesn't need it. There's no standard for udp:// or at least there wasn't one when VLC introduced that, so your comment doesn't make much sense.

[tangent]

@ is part of the URL standard, and you're free not to use it if your use case doesn't need it.

My point is that there is no need to make the @ mandatory in VLC's case. "udp://239.255.1.2:3456" has an unambiguous meaning that's so clear I don't even need to explain which resource it is intended to access.

The problem here is that VLC operates differently if you run it as "vlc udp://239.255.1.2:3456" vs "vlc udp://@239.255.1.2:3456". It should give the same result.

If you disagree, then I want to know what useful behavior the first command is intended to produce vs the second, because that is the behavior you are protecting by refusing to change this URL parsing logic.

[Rémi Denis-Courmont]

The @ is not and never was mandatory as such. You can argue that the choice of default is unfortunate, but that's easy to say with 20+ years hindsight.

Raw UDP was deprecated over 15 years ago and it's only left there for backward compatibility. We can't change the syntax, lest we break that compatibility. If you can afford to change stuff, use RTP.

[lysek]

I noticed that RTP protocol does not require the @ sign in the address and thus rtp:// links works in new versions of FF/Chrome. Is it perhaps possible that there is some kind of auto-detection of IP address type (multicast VS unicast) when parsing RTP feed URL in VLC? Could same approach be used for UDP URLs?

[Rémi Denis-Courmont]

There's no autodetection of anything. RTP just uses a better default because it was defined later with the benefit of hindsight.