Added support for gifdeliverynetwork/redgifs in GfycatRipper and Added Soundgasm Ripper

[borderline232]

Category

This change is exactly one of the following (please change [ ] to [x]) to indicate which:

• [x] a bug fix (Fix #1680 )
• [ ] a new Ripper
• [ ] a refactoring
• [ ] a style change/fix
• [ ] a new feature

Description

• Added an additional check in the getVideosURL function to check for redgifs URLs if initial check fails
• This may need to change depending on if gfycat changes the way they handle the redirects in their document
• Uses previous implementation found in older releases of ripme

Testing

Required verification:

• [x] I've verified that there are no regressions in mvn test (there are no new failures or errors).
• [x] I've verified that this change works as intended.
  • [x] Downloads all relevant content.
  • [x] Downloads content from multiple pages (as necessary or appropriate).
  • [x] Saves content at reasonable file names (e.g. page titles or content IDs) to help easily browse downloaded content.
• [x] I've verified that this change did not break existing functionality (especially in the Ripper I modified).

Optional but recommended:

• [x] I've added a unit test to cover my change.

[borderline232]

Per @CaptRussia it seems to have trouble with some old legacy gfycats that don't get transferred over to redgifs properly

Atm the current implementation is able to scrape most of the newer vids that get transferred from gfycat to redgifs using the mp4Source found in the HTML of the redirected page (click gfycat -> redirects to gifdeliverynetwork -> view source -> find mp4Source). The problem is that sometimes the mp4Source is not valid, but the webmSource is and sometimes even that is not valid. The only reliable source in the HTML is the contentUrl in the script tag which usually links to a mobile version of the mp4 and happens to be lower resolution to the other's mentioned.

So I was wondering which method you'd want to use? We can only do one because there really isn't a way to check the validity of each URL until we actually rip it (I believe).

Keep mp4Source (mildly reliable + high res) Keep webmSource (medium reliable + medium-high res) Keep mobile.mp4 (highly reliable + low res)

[CaptRussia]

I'm not familiar with the intricacies of the ripping process that Ripme uses, however, would it not be possible to fallback onto the different versions upon a failed ripme attempt?

For instance, it would attempt the mp4 source. If that failed it would move onto attempting the webm source. And failing that, the mobile.mp4 source. Would it be possible to implement such a fallback feature? In theory, I think it would make sense, however, Java isn't my language and so I can't comment on the feasibility of implementing it.

Failing that. I'd suggest adding a config option for the user to specify what option they would prefer. That's less than ideal though as it would be adding bloat to the config option that only one ripper would be utilising.

For fear of beating a dead horse, I think the fallback implementation would be the best route. It would capture the best quality possible while also offering maximum reliability. Failing that. I'm partial to having maximum reliability and so if I had to I would vote for ripping the mobile.mp4.

[borderline232]

Accidentally forgot I still have a PR open but I added a soundgasm ripper which works fine.

@cyian-1756 could you merge this in when you're free thanks

[soloturn]

put 2 of the commits onto https://github.com/ripmeapp2/ripme/actions

the other one contained classes, and mixed 2 unrelated things into one commit. would you mind splitting it?

[soloturn]

took out "upport for redgifs support in GfycatRipper" as the tests were failing.

[borderline232]

@soloturn yo, you still want me to put the commit in the other fork?

Also, to clarify my own fork which I used to create the pr (borderline232/ripme) is a little bit ahead and has bunch of new commits from the master branch of this one, so this PR just keeps adding the stuff that's on mine.

[Anon1337Elite]

@borderline232 @soloturn has this been fixed the gifdeliverynetwork issue ? If it has been can someone provide the compailed .jar file where it works ? Thanks. Just saw ur builds borderline it works there nice.

[soloturn]

@borderline232 i cannot make out which commit we should merge. would be great if you could create a pr for https://github.com/ripmeapp2/ripme/tree/main.