| 4 Apr 2024 |
 Ward | In reply to @absidue:matrix.org
If you want to use the adaptive formats for anything other than audio-only playback, you'll need to use a javascript player e.g. shaka-player, video.js, dash.js anyway (as you'll want to stream both an audio and a video stream), so you can just tell whatever player that you decide to use to add the custom headers. aside from most players using the video element at their root, what doesn't support custom headers | 08:06:56 |
| Ward | what includes video.js i believe | 08:07:36 |
 absidue | In reply to @wardpearce:matrix.org
aside from most players using the video element at their root, what doesn't support custom headers While yes the wrap the video element, they fetch the data themselves, merge the audio and video streams and then pass the raw data directly to the video element. | 08:07:46 |
| absidue | In reply to @wardpearce:matrix.org
aside from most players using the video element at their root, what doesn't support custom headers * While yes the wrap the video element, they fetch the data themselves, merge the audio and video streams and then pass the raw data directly to the video element with the Media Source APIs. | 08:10:13 |
| Ward | *in some cases, videojs still uses the native video element sometimes | 08:10:33 |
| absidue | In reply to @wardpearce:matrix.org
*in some cases, videojs still uses the native video element sometimes Yes if it only has to play one stream, so the non-adaptive formats or if you decide you want audio-only or video-only playback | 08:11:04 |
| Ward | plus it seems easier to just have an option to pass auth via a url flag in the api too so it can work with native html | 08:11:10 |
| absidue | In reply to @wardpearce:matrix.org
plus it seems easier to just have an option to pass auth via a url flag in the api too so it can work with native html easier but makes auth completely pointless | 08:12:07 |
| Ward | how so? | 08:13:12 |
| Ward | how often are users sharing API requests they don't see | 08:13:31 |
| absidue | In reply to @wardpearce:matrix.org
how often are users sharing API requests they don't see They can easily see it though, all they need to do is right click the video element to copy the URL and then they have your token. | 08:14:30 |
| Ward | who's they? | 08:15:07 |
| Ward | if the share the watch url with it don't have their token | 08:15:24 |
| Ward | * if the share the watch url, it wont have their token | 08:15:44 |
| absidue | In reply to @wardpearce:matrix.org
who's they? Well you've clearly added restrictive auth to your instance for some reason, which means it's probably not just for personal use. | 08:16:17 |
| absidue | In reply to @wardpearce:matrix.org
who's they? * Well you've clearly added restrictive auth to your instance for some reason, which means it's probably not just for personal use, otherwise you wouldn't have locked down the streaming URLs too. | 08:17:23 |
| Ward | the apdativeStream sources are locked down by default if your using Invidious as a proxy | 08:18:02 |
| Ward | I'm asking if its possible to auth the sources to them without headers, because native video element doesn't support that | 08:18:45 |
| Ward | if someone shares their watch url, e.g. /watch?v=123 they aren't gonna get the users auth token being used internally in the interface | 08:19:25 |
| absidue | In reply to @wardpearce:matrix.org
the apdativeStream sources are locked down by default if your using Invidious as a proxy How are you adding auth to your instance? | 08:22:08 |
| Ward | my instance of what? Invidious? I'm talking about Invidious' API not the instance itself | 08:23:46 |
| Ward | because I'm using the API for my own project | 08:24:00 |
| absidue | In reply to @wardpearce:matrix.org
my instance of what? Invidious? I'm talking about Invidious' API not the instance itself The API is part of the instance. | 08:24:30 |
| Ward | sure but not sure how "how are you adding auth to your instance" is relavent | 08:25:36 |
| absidue | In reply to @wardpearce:matrix.org
sure but not sure how "how are you adding auth to your instance" is relavent Because as far as I can tell from looking at the Invidious config file it doesn't support the kind of authentication you are talking about. Which means it's probably added by a server running in-between Invidious and the user, so you would have to ask the maintainer of the instance you are using how their auth is handled and if they can add support to their server in the middle to extract the token from the URL. | 08:26:20 |
| Ward | Why type of auth am i talking about? | 08:27:27 |
| absidue | In reply to @wardpearce:matrix.org
Why type of auth am i talking about? auth on the streaming URLs, which Invidious doesn't do by default | 08:27:41 |
| absidue | the streaming endpoints are unauthenticated | 08:27:50 |
| absidue | the only ones that require authentication are the ones that access users data e.g. the subscriptions feed or the watch history | 08:28:17 |
| Ward | doesnt appear to be correct, this is a instance im hosting locally with only caddy sitting in between docker. Making a request to a adaptive format video URL why proxying it gives a 403 error | 08:32:46 |
