If you’ve been annoyed at loops in this community not getting embedded, try out Tesseract (https://tesseract.dubvee.org/). It’s an awesome Lemmy UI made by @[email protected] that supports embedding loops (along with many other neat features), and embeds them as regular video files, give you browser-native controls like seeking and volume control.
More information can be found in the release announcement:
https://dubvee.org/post/2439012
Note that it’s still considered beta, so is only available yet at the hosted instance https://tesseract.dubvee.org/. Testing and bug-hunting is appreciated:
Again, testing and submitting buts is extremely helpful as I cannot test every possible scenario.
You must log in or register to comment.
Thanks for the shout out. Definitely still a beta feature, but it seems to be working very well. Hopefully Loops doesn’t do something user-hostile and block non-browser traffic with Cloudflare or something because that would break this integration. At least I’m being considerate and caching the lookup responses lol.
Any testing/bug reporting is appreciated, but one area where it would be extra appreciated is on iOS. I no longer have an iPhone to test with, so that’s been a testing blind spot for several months now.
This is fantastic! I have seen no bugs so far but I will let you know if I do. In fact the ability to control the video offers more functionality than the standard webpage player does (without an account)!? And as for the rest (attribution) there is always the link to it directly.
One thing I would suggest is to stop playing the video as the page scrolls downwards. Probably you already had that planned:-).
I said it already but I want to say it again: this is fantastic!:-)
One thing I would suggest is to stop playing the video as the page scrolls downwards. Probably you already had that planned:-).
It should already do that for all media, unless it’s just broken in the Loops component; I’ll take a look shortly. Any active media should return to a thumbnail when it’s out of the viewport for 2 seconds (the countdown disarms if you scroll it back into view). It used to stop the video and return it to a thumbnail immediately when the post left the viewport, but I added a 2 second delay because resizing the browser window would destroy the video if it went out of frame and that was annoying lol.
If it doesn’t do that (for any media), can you let me know what browser/device you’re using?
Ah that is it. I was too impatient to wait the 2s, so especially for those actively playing sound I kept going back up to immediately stop those, before scrolling down and continuing.
It’s a conundrum b/c the UX “model” here is different (I am not a UI/UX developer though so just a thought:-P): on the Loops single-video pages the videos constantly loop forever, and that’s fine, but if you are scrolling through and want to watch many, then I was thinking that it taking 2 clicks (once anywhere on the video to bring up the controls at the bottom, and the second has to land right onto the pause button) is a bit of a barrier. Theoretically then, for an embed you could have it play only once perhaps? Assuming you had control over that (I see that I can right-click and choose that as an option, but then if I scroll away and return, it returns to the default setting of infinite looping; so here I mean to facilitate the playing in an embed as opposed to a dedicated page of its own, to change the default setting as you load it). Or perhaps for super-short ones below some threshold, allow it to restart but then for longer ones halt after a single play? Either way its nice that the user can still change the behavior for a single video, e.g. in case they wanted to listen to some music on repeat forever. I suppose another way that they could do the latter is, once the video has been “discovered” in this manner (with the embed in the community), to click to the single-video page and THAT one will Loop forever. So: different UX behavior for a different purpose in the embed vs. on the actual individual video page.
In any case, the halt upon scroll model definitely seems a good one too, though at first I did not realize that it really would pause if I simply waited? Perhaps you can reduce the wait time - would 0.1 seconds work? 0.5? (to not cause the browser resize issue I mean) If all it did was pause the video rather than stop it - and therefore it could resume at any time - then it would be no loss at all to do so. Except that ofc would require more memory. As it is now, where it truly stops it… well, nothing can be perfect, but I still think it’s not so bad to stop it upon a scroll? Someone can either watch the video, or indicate their readiness to move on, but if they stop it that way, that’s on them for sending the wrong signal, by scrolling rather than watching patiently?
So, you are the expert here, but if it helps to receive that kind of feedback, my preference probably would be to have the video stop after one play-through, and second place preference would be to halt upon scroll with a shorter delay. Also I would guess that you’d need the second one either way, for memory reasons? (or if it were possible perhaps you could kill not the last video but the second-to-last, thereby leaving the last one in memory to resume quicker if someone decided to do that - thereby enhancing the feeling of “snappiness” of the interface, without compromising much in terms of memory since these are all fairly short videos:-).
I hope this text isn’t all too much. I already think it’s fantastic just the way it is, and all the more so now that I know that it will halt upon scrolling, though the above changes I think would act as improvements to make it more intuitive. Do as you please of course, and I will be interested to see how it turns out!:-)
