I’m trying to specify a port in the URL string I use to set the URL. It works in PCVR but does not contact the server in native Quest. This leads me to believe that it isn’t supported.
example:
https://test.com:8443/endpoint
I haven’t tested this month, but ports work on Quest.
Are you keeping in mind the gotchas for quest? No http, only https. Cert must be signed, URL must be a playable item, not a web page that yt-dlp can sort out in the background.
Thanks. I would have guessed that a port was supported but I had run out of options. I’m using https, the cert is legit. I’m respond with a redirect which as far as I know should be valid. In fact I’m 99.9% certain that I ran a successful test before making a commitment to changing my VRChat world.
I have a hard time believing the response is invalid. Could be but I’m logging the requests and they aren’t getting logged which seems to indicate something is restricting it. I have set the trusted URLs setting and I’ve also tested with other similar 3rd party servers. I just tried a direct link to the “Big Bunny” test video and it worked as well.
I’m running out of guesses 
Personally for testing URLs I’ve been using a particular world called Video Player & Mirror
When you’re hitting your server on the different port, are you able to have it serve out redirects and optionally some directly served files? If the redirection is a thing worth mentioning it, try removing it.
I can’t recall if it was of any use, or why, but at one point I had fired up a packet sniffer to inspect the session initialization. If the server and the client disagree on “ciphers” you’ll see it there. Just make sure the copy of wireshark that you’re looking at packets in is up to date. Like if its a remote server you can run tcpdump (filter it to the port of the webserver) and then copy the dump to a local computer.
So my suggestions in order that I’d try
- Redirection types, the perm vs temporary
- try handing out a video file. make sure its over a minute if you’re throwing it into a video player in a world
- Looking at packets for TLS/SSL initialization is the most annoying so investigate that last? “ciphers” , not crypts.
Also any sort of server probably has a sensible default configuration.
Ah that might work as a test. Basically use my server as the URL for a player we know works. Still my player works using several 3rd party servers including the Jinnai one that has been closed.
I can’t think why VRChat would be concerned with the type of redirection but I can try it. It surely isn’t making note of permanent redirections (I hope).
The real problem of problems is that VRChat is not sending the request or I would see it on my server logs. Changing the response isn’t going to have any effect until I see the request.
Would a failed tls negotiation show in the log that you’re looking at?
I currently don’t watch for such errors. I (perhaps incorrectly) assumed they would show up in the error log. I’m researching my options to get more info from my server.
It would tend to explain the behavior I’m seeing. Seemingly no connection to my server and possibly a handled error on the VRChat client which I simply cannot see.
Thanks again…
Requests from media players on Quest require HTTPS with a valid cert. I don’t know about alternate ports though.
There are also some cursed limitations (bugs) like you can’t 302 to an HLS playlist
Strangely, string/imageloader don’t require https…
On quest video request doesn’t come from VRChat, the request come from exoplayer, the software that decodes and plays videos.
Recently exoplayer is now called media3 but I’m not sure if the version used by VRChat (via AVPro) has caught up yet
Oh excellent info. Are you aware of any docs re: it? Ah, I found the website… thanks.
Not sure if this apples in your case, but I’ve noticed players will handle video (files) vs streams (a live stream) a little differently, for example iwaSync3 has different settings for both.
If it helps, ArchiTechAnon ProTV has a walkthrough of their features here: ProTV by ArchiTechAnon | Usage Guides and Walkthroughs
I’ve been able to stream audio and video that use dedicated ports on both PC and Quest, though YMMV depending how this is delivered (would guess this has more to do with the network, but I’m no CCIE).
As @docteh mentioned, if the codecs/format of the file itself are natively supported by Quest (as in the mpeg4 “bigbuckbunny blender demo” you tried), then you’re good, otherwise it will indeed fail …
That said, the solution might be to re-encode your video into a more quest-friendly format.
When working on worlds I’ve often put in two different playlists, using YouTube for PC users, and a similar selection of music or movies from archive.org for the Questies.
Not sure if that was helpful, just adding from personal experience ^^
In case anyone else runs into such an issue. The certificate didn’t include the entire “chain of trust” and while that doesn’t affect a website it does affect VRChat. So a few tweaks and it is working now.