murillo128
commented
1 month ago Those methods are completely ad-hoc, and can't be used on an IETF spec.
We could define a different uri scheme like whep:// although not particularly recommended https://www.rfc-editor.org/rfc/rfc9205.html#section-4.4.2
Many of the video player SDKs (generic ones, not ones from providers) use file extensions or specific urls to know how to play content. Take HLS with the .m3u8 file extension. You can call a url that ends in .m3u8 and know its a HLS stream. You can call a vimeo or a youtube url and know how to handle that.
Getting into providers that support HLS,DASH and WHEP... should there be a "file extension" or some other form of standard inside a url structure to know that "this is a WHEP url" ?
I'm curious to know what other people think on this one. If you take a look at ReactPlayer it has a load of javascript classes for handling specific providers and generic HLS for example... and then it has a load of regexes to know that a url given to the player is youtube... so bring in the youtube specific provider, or no specific provider was found but .m3u8 was found and so handle generic HLS.
Should WHEP enable discoverability of a URL for something like ReactPlayer (and all the other players that do this) to know that it is indeed a WHEP url and can be treated rather generically.