refactor(extractors): simplify and combine jwplayer extraction#2398
refactor(extractors): simplify and combine jwplayer extraction#2398Bnyro wants to merge 1 commit intorecloudstream:masterfrom
Conversation
library/src/commonMain/kotlin/com/lagradost/cloudstream3/extractors/helper/JWPlayerHelper.kt
Show resolved
Hide resolved
library/src/commonMain/kotlin/com/lagradost/cloudstream3/extractors/helper/JWPlayerHelper.kt
Show resolved
Hide resolved
a45b9d4 to
5a4d16b
Compare
|
I am reworking some extractors. I recently fixed Vidmoly that would benefit from this utility as it fits in the same class of jwplayer config string. On the other hand you mention Filemoon, but it is no longer working since now the load of the iframe page is way more complicated and behind several scripts. |
Yes, true. I only noticed that Streamwish, Filesim and Filemoon use almost the same code, so it's possible that they're all the same provider (i.e. the same company hosting it), that note is not meant to be related to JwPlayer. |
5a4d16b to
2d94d8a
Compare
I noticed that a lot of extractors are based on the following pattern:
scriptfile containing JWPlayer configPreviously, all extractors had their own logic for extracting the JWPlayer config, even though the JavaScript data parsed always looks the same. So there's been a lot of duplicated code that behaved inconsistent (i.e. some only supported
m3u8links and no other stream types likemp4and others didn't parse the subtitles).This logic is now handled by
JWPlayerHelper.kt.I've also noticed that some of the files could be merged, e.g.
contain almost the exact same logic and
also do the exact same thing. I suspect that all these providers are based on the exact same code (only some UI changes), but I haven't moved their extractors into the same class yet because I'd like to hear some other opinions first before doing that.
The deleted files are usages of the JWPlayer API on sites that no longer exist, so I removed them.