Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(PreviewCard): gtuber #1171

Closed
wants to merge 1 commit into from
Closed

feat(PreviewCard): gtuber #1171

wants to merge 1 commit into from

Conversation

GeopJr
Copy link
Owner

@GeopJr GeopJr commented Oct 21, 2024

Welcome youtube, twitch, bilibili and a gazillion other services to the clapper version

TODO:

check what plugins are available in advance?

@GeopJr
Copy link
Owner Author

GeopJr commented Oct 21, 2024

@Rafostar Do any of these services need a uri scheme substitution like peertube? bilibili, crunchyroll, invidious, niconico, piped, twitch, youtube

(also I caught another one of these weird freezes, I'll take a closer look, the post is https://mastodon.social/@hiromst/110426877145818741

Screencast.From.2024-10-21.06-24-25.mp4

, my guess is probably that Tuba disposes the clapper instance while it still processing stuff)

@GeopJr GeopJr marked this pull request as draft October 21, 2024 03:49
@Rafostar
Copy link
Contributor

Rafostar commented Oct 21, 2024

Hi,
Just FYI, there is an ongoing effort (one of the reasons no Clapper 0.8 yet) to deprecate gtuber as it is. In a sense that all the "good stuff" will be ported/moved to Clapper monorepo, while the rest either simplified, dropped or improved/changed while at it.

It was made long before Clapper libraries existed. Nowadays it actually limits some possibilities/things I could achieve in Clapper and other apps that want playback can simply embed Clapper, so decision was made to move this functionality to Clapper monorepo.

While old implementation will continue to work, it will probably end up unmaintained once new functionality is (hopefully) finished. So you can test playback, but might want to reconsider merging it now (and forcing package maintainers to add it too).

Do any of these services need a uri scheme substitution like peertube

The basic principle/reason for this is that services that are self-hosted use URI scheme to explain that this host is this service instance and should be treated as such.

also I caught another one of these weird freezes

Feel free to open any issues you have on Clapper repo. I will try to look into them before 0.8 and even if we miss something there shouldn't be any problem doing patch version release with a fix 😄 . Right now of the few apps that use libclapper, Tuba is the only one that disposes it in the middle of app lifetime (so catches those issues).

@GeopJr
Copy link
Owner Author

GeopJr commented Oct 21, 2024

I see, thanks for the info! I guess I'll close this and re-visit it when 0.8 comes out!

My main feature request for when gtuber's functionality gets added to Clapper, would be something similar to Gtuber.has_plugin_for_uri, so I know if Clapper can handle a uri or if it should open in the default browser :)

Feel free to open any issues you have on Clapper repo

I'll do so after I debug it a bit further, thanks!

@GeopJr GeopJr closed this Oct 21, 2024
@Rafostar
Copy link
Contributor

My main feature request for when gtuber's functionality gets added to Clapper, would be something similar to Gtuber.has_plugin_for_uri, so I know if Clapper can handle a uri or if it should open in the default browser :)

I will keep this in mind. Just remember that having a plugin doesn't necessary mean that extraction will succeed.

@Rafostar
Copy link
Contributor

My main feature request for when gtuber's functionality gets added to Clapper, would be something similar to Gtuber.has_plugin_for_uri, so I know if Clapper can handle a uri or if it should open in the default browser :)

@GeopJr

While I continue on porting gtuber into Clapper, thinking about your request here, I realized that... this API does not do what you actually want! 😅

In reality your Q&A is:

Question: Can Clapper play this URI?
Answer: Clapper uses GStreamer, thus it can play anything that you have a GStreamer plugin for.

So, how can you know that GStreamer supports this URI?
Simple, use gst_element_make_from_uri API and check whether it returned NULL.

But as I mentioned previously, this never gives you 100% chance that it will actually play and does not encounter any errors when trying to do so. Use only if you really, really need to check ahead of time. Normally app should just try to play content and if it encounters a missing-plugin or an error handle them somehow (for example by giving alternative way to play content via browser). Thats at least my friendly suggestion 😄 .

@GeopJr
Copy link
Owner Author

GeopJr commented Oct 25, 2024

Simple, use gst_element_make_from_uri API and check whether it returned NULL.

I wouldn't expect it to work when providing platform websites instead of direct links to the streams, should I? I mean, I expect gst_element_make_from_uri to return NULL if I provide it with a youtube.com/watch?v=... url

Either way, that's only partially of what I need 😔

If gtuber-in-clapper has a modular design like gtuber does currently, where you can build it with only some services, I'd still like some way of knowing what's available. That way if a distro has built Clapper (with gtuber) but has enabled only youtube and twitch, Tuba would know in advance. It can be an array of an enum or something for all that matters:

if (uri.get_host () == "youtube.com" && Gtuber.Platform.YOUTUBE in Gtuber.available_platforms) {
  // open in Clapper
} else {
  // open in browser
}

@Rafostar
Copy link
Contributor

First of all, nice that I can brainstorm the ideas with someone regarding this in the middle of making. Thanks for your input 👍

I wouldn't expect it to work when providing platform websites instead of direct links to the streams, should I? I mean, I expect gst_element_make_from_uri to return NULL if I provide it with a youtube.com/watch?v=... url

Not entirely. If you want to support only a single plugin (previously gtuber, now its replacement) you can pass its name as an arg to this function, then it will return NULL when either: Clapper not compiled with this functionality or if a YOUTUBE module is not available.

Alternatively, if you want to support only a select few elements you know names in advance like gtuber, new one (name still undecided) and so on. You can make it from GstElementFactory (returns NULL == whole plugin not installed), then set its URI with gst_uri_handler_set_uri (returns FALSE == no YOUTUBE module, repeat both steps for the next known element). It gives you more info what is missing this way and you can fallback to another element you know (like gtubersrc).

Third option that might be more universal I can think of is to use gst_element_make_from_uri with NULL arg as element name, then check if anything returned AND if returned element does not happen to be one of the "stock" httpsrc elements (by for example checking its name/suffix). Either gtubersrc or new one I am working one will not return here when a YOUTUBE module is not available.

@GeopJr
Copy link
Owner Author

GeopJr commented Oct 26, 2024

I see, thanks for the info!

My main concern with calling gstreamer just for checking if a url can be handled is that it might be too expensive for my use case. Plus it's not like the element will be used afterwards, when the url gets passed to Clapper it will do the same thing again, so it's a bit wasteful.

The use case here is that if someone posts a youtube, twitch etc url and a preview card shows up, like this
image
when users click it, it should attempt to open the video in Clapper, play a funkwhale song in the mediaviewer or open a bookwyrm book. But, if it's a normal website, like the one in the screenshot above, then it should open straight in the browser. I can kind-of detect the platforms I support in advance, before doing any API requests, so it's generally fast if you open a normal link since it will skip all of the processing.

The gstreamer approach would require me to pass every link through it, just to see if it's something gtuber-in-clapper supports.

Having a static list of platforms from my side is also not ideal* but it might be better than passing everything through gstreamer:

string[] supported_platforms = {"youtube.com", "twitch.tv"};

bool can_handle = false;
if (uri.get_host () in supported_platforms) {
  try {
    var element = Gst.Element.make_from_uri (Gst.URIType.SRC, uri.to_string (), null);
    can_handle = element != null && element.get_type ().name () == "GstGtuberSrc";
  } catch {
    can_handle = false;
  }
}

if (can_handle) {
  // open in Clapper
} else {
  // open in browser
}

that way we only create gst elements if the uri matches a supported platform.

*It's not idea because it won't benefit from any gtuber-in-clapper platform additions or removals automatically; it would require Tuba to bump them and make a release

I think I'm probably overthinking it and it's more straightforward than what I have in mind :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants