I haven't looked into this yet but for completion:

• The download process is on https://github.com/GeopJr/Tuba/blob/main/src/Utils/Host.vala#L37-L71
• And the path gets set as the GtkVideo's filename

Ideally, I'd rather we streamed these rather than downloading them and then playing them but it's blocked by https://gitlab.gnome.org/GNOME/gtk/-/issues/4062 which is blocked by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/724

Ideally, I'd rather we streamed these rather than downloading them and then playing them but it's blocked by https://gitlab.gnome.org/GNOME/gtk/-/issues/4062 which is blocked by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/724

Ah, that's great to know, will put that on my list to look into.

Ideally, I'd rather we streamed these rather than downloading them

Hi, I dunno how Tuba would feel about using 3-rd party stuff, but it could technically use/integrate Clapper in its UI for playback, which:

a) Can actually stream video like this without the need to download (which seems inefficient for social media client - and video from this issue doesn't seem to crash caused by download since there is no download)
b) Can stream with working seeking Peertube videos (both HLS and MP4 - your issue #662) - you just have to replace https:// URI scheme with peertube:// to let it understand that this website hosts peertube
c) Has VALA bindings support (working example/test app here)
d) Has overall more features (more expanded APIs then GtkVideo which is very simple/minimalistic)
e) Lets you customize/build your own overlay playback controls panel with buttons/features that best suit your app if needed

Someone asked me to let you know about possibility. Please just ignore this comment if uninterested.

Cheers!

Hey, thanks for dropping this here. I didn't have a deep look at the Clapper lib yet, but I think it's worth thinking about. In order to make the tech stack not too complicated, I further wonder if parts of the clapper libs could be upstreamed to Gstreamer or GTK instead - or if existing components could be improved to take over the job.

upstreamed to Gstreamer or GTK instead

This issue is probably not gonna be best place to discuss this. I cannot find the link anymore, but I were told by one of GTK Devs (I think it was few years ago already) that GTK gives GtkVideo as something simple and more of a example then fully featured video player, and they are not interested to make and maintain something bigger then that as part of their Toolkit (comment which I fully understand and actually agree with).

GStreamer on the other hand already gives a playback API (GstPlay) which is more universal for other GUI toolkits and works differently (its a whole different API, without any sort of GTK integration/shared widget functionality - lots of stuff needs to be redone in app) then the one I did to optimize/target GTK specifically. They cannot be "merged" without breaking API/ABI compatibility and they won't want to maintain multiple APIs that do something similar but differently.

So yeah, I do not think this is gonna belong anywhere but inside its own repo, similarly like libadwaita. That is also why I am not gonna force anyone to use it 😄

Edit: Also, isn't this too early to even start a discussion on this topic? 🙃

From Tuba's side, I'm very interested in using clapper, especially if it solves issues with streaming and #749 (@rmader that might interest you too, I can't reproduce it on qemu or desktop 🤷)

Turns out that https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/724 has long been fixed (in Gst 1.22.1, i.e. old stable), so maybe we can already enable it with just a few lines changed.

Hm, just opened #925 which (IIUC) enables streaming - and seems to solve the issue here 🤷

Unfortunately we're loosing the cache then, I wonder if we can improve on that.