Thanks for your reply, @Rachel. The first reason is that I generally approach third-party libraries with caution (for better or worse), primarily for the avoidance of bloat. I'm not opposed to doing so where it makes sense, but the benefits weren't immediately obvious to me over the flexibility and control granted by the HTML5

<video>

element + a CDN (Cloudflare Stream). Having said that, I don't have a lot of experience with video. Dynamic bitrate seems like it could be helpful, so that could be a reason to try the CF player. Cost isn't a concern yet but I will definitely have to keep an eye on it if/when traffic for this project picks up. My use case is definitely shorter videos, FWIW. For reference, the video I'm testing with is 59 seconds long. I suspect a "long" video for my use case will be on the order of 3-5 minutes. EDIT: oh, and I'm not doing anything "live" (yet).

Also, I think that this isn't true: > Download link video is not seekable; Here's a demo of my WIP player, which seeks super fast!

It is probably because the video was downloaded quick. May not be true for larger video

perhaps. But the

<video>

reference docs do describe seek controls + seek events: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/seeking_event https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/seeked_event Again, I'm new to doing almost anything with video. I've always just used YouTube in past projects.

I think though that you have confirmed my suspicions, that the biggest differences for my project are at least dynamic bitrate, and potentially $$$.

@Rachel thanks again!

TIL! Thanks for these! 👍

You can customize a lot with a third party player

you can put comic sans on the font, make control icons to be cats and dogs and dragons

Is the resource URL provided by WHIP meant to be the same as the endpoint url itself?

for our implementation, they should be different

hmm

libcurl is giving me a location path that appears to be the same as the main url

I hope libcurl isn't overwriting the location header or something

@Rachel Quick suggestion. When sending POST to the whip endpoint url, if the url doesn't exist, cloudflare currently returns a 400 code. Any chance that could be changed to 404?

they look kind of similar, maybe your eyes are lying

i will do that tmr

I've checked with my eyes as hard as I can. I'll do some quick debug logging though to make sure my curl url implementation isn't doing something funky

Ahh my bad, curl's url redirect example for their url util seems to have misled me

Ah ha, I need to strip the ends of my header strings because curl isn't liking it

The OBS WHIP PR is now officially back to near feature complete state running with libdatachannel \:) If you want to test it (and I highly recommend you do, it is built strictly to the WHIP spec and has good error handling), you'll unfortunately have to build from source, as the CI artifacts are built with the plugin disabled right now

@tt2468 When WHIP hits mainline, I assume we can submit webrtc services too following https://github.com/obsproject/obs-studio/wiki/Service-Submission-Guidelines ?

We have an upcoming large refactor of that stuff, including services, but when it's all done you should be able to submit services that accept WHIP

just to follow up, we're seeing the same issue regularly. using hls.js the quality chosen is wildly inconsistent

100%, and not just hls.js but pretty much every third party player

@tt2468 do you have build instructions on darwin/arm64?

Time to build OBS with WebRTC

Ugh why do I have to pay for video storage that I will never use

I do not unfortunately

I would be interested in that as well