search

Erk- / rsget

A downloader for different live stream providers
ISC License
23 stars 5 forks source link

Rsget 2.0 #12

Open Noxime opened 5 years ago

Noxime commented 5 years ago

What

This issue is for the discussion of rsget's API overhaul and the design choices that should be taken in preparation of 2.0 release

Why

The current rsget_lib and stream_lib design is currently not flexible enoug. As a real life example of this, lets look at the plugin for https://vlive.tv.

The way vlive.tv api works, is they require what I will call session key and internal video id. the internal video ID is different from the user facing id, which is referred to as the video sequential. In order to make video scraping more difficult, vlive.tv renders the key and and id into the html page on the server side, which luckily we can quite easily parse. With the key and id you perform a call to an api endpoint, returning JSON about the video. This is where the troubles begin. The URL returned requires authentication in the form of an additional query parameter added to the end of the URL. This too would be okay, but the key must also be appended to the URLs listed and be appended to the final .ts file URLs. This is currently not possible due to SteamType's HLS variant not taking any parameters that might allow this behavior. The vlive.tv backend is forced to use VOD files, meaning no support for live streaming and some qualities may not be available.

What should be done

One option would be to extend the StreamType enumerator in stream_lib to accept more options for more flexible behavior. Unfortunately while this would be a fairly quick ad-hoc fix, over time as more backends are added, the options might get unwildly and will never cover every possible way some API might behave. Therefore I propose an effort to redesign stream_lib and rsget_lib to a more lower level, more flexible form where more responsibilities are moved to the backend implementations. This way more APIs can be supported more seamlessly and with less "hacks". What this new design looks like, I am not sure. I dedicate this issue for the discussion of what that future might look like.

Erk- commented 5 years ago

About stream_lib

I think the best course of action would be to make stream_lib its own thing so it can still be used, as it works for most sites, though extend it with needed options eg maybe parse a Option struct to it. I agree that rsget_lib should be made less dependant on stream_lib so maybe make a trait to return from the get_stream method or remove it, in favour for a download method and a get_media_info method. It would be very annoyiung if everyone would have to pretty much reimplement HLS as the standard is annoying enough already. stream_lib is not really up to the task yet, but that is the first part of the suite I am planning to rewrite.