GeopJr
fix(mv): clapper: GIFV handling fixes
Some fixes mainly related to handling multiple GIFV in a single post. More info in individual commits descriptions.
Ideally, Tuba could be more efficient by creating a single video instance, putting multiple GIFV in Clapper Queue and just switching between them (maybe even with overlaid pre-made NextItemButton / PreviousItemButton) instead of creating multiple video instances and switching widgets. Unfortunately, this would be probably too much/hard to implement while retaining support for GtkVideo which is the default backend within a single source code file, so for now a few changes working around that to remain compatible :smile: .
LGTM, thanks!
I want to do some deeper testing with some extreme cases and I'll merge it afterwards
Ideally, Tuba could be more efficient by creating a single video instance, putting multiple GIFV in Clapper Queue and just switching between them (maybe even with overlaid pre-made NextItemButton / PreviousItemButton) instead of creating multiple video instances and switching widgets. Unfortunately, this would be probably too much/hard to implement while retaining support for GtkVideo which is the default backend within a single source code file, so for now a few changes working around that to remain compatible 😄 .
Unfortunately there's a lot at play :(, for example, even the attachment position matters and if there's: GIFV, GIFV, IMAGE, GIFV, then it would need at least 2 Clapper instances. Position matters sometimes, like in the case of documents where each attachment is a different page etc.
Maybe we could use a queue if all the attachments are videos? (but that will complicate things a lot, so let's just leave as is for the near future :sweat_smile:)
so let's just leave as is for the near future
Absolutely. Doing it like it is done currently was my intention, hence this PR.
GIFV, GIFV, IMAGE, GIFV
In ideal scenario, there would be exactly 1 video player instance (since Tuba shows only 1 video/GIFV at a time) and media viewer is something that can show both videos and images (e.g. a GTK Stack with video and picture viewers that switches between these 2 child widgets when needed). If it could hide itself instead of destruction when unneeded/done that would be even better. There is a lot of work going on (between GTK and GStreamer) to prepare for video playback (not to mention decoders and separate memory pools of each pipeline, etc.). Afterwards, most of it does not have to be done again when video widget is recycled. This is true for both GtkVideo and Clapper that use GStreamer internally, so both would benefit.
I just wanted to mention that. This is just a friendly TIP, for how this can be optimized (how can but its not a must, just optimization). I do not want nor plan to meddle with someone else's app too much. Just trying to give some friendly pointers/help and nothing more :smile: .
I just wanted to mention that. This is just a friendly TIP, for how this can be optimized (how can but its not a must, just optimization). I do not want nor plan to meddle with someone else's app too much. Just trying to give some friendly pointers/help and nothing more 😄 .
Thank you for all the info! I value your opinion and knowledge on the matter and really appreciate it :) Feel free to share your thoughts whenever you feel like it!
Seems to work fine (at least for me :smile:) and does what its supposed to do (no MPRIS for GIFs and no buffering/download for remaining videos/gifs when only one is selected), so I am unmarking this from being a draft.