search

NO-ob / LoliSnatcher_Droid

A booru client with support for batch downloading
GNU Affero General Public License v3.0
371 stars 23 forks source link

DRAFT: Initial media_kit/mpv backend #175

Closed drwankingstein closed 3 months ago

drwankingstein commented 1 year ago

port to the new media_kit project, this is very much a draft, as there is plenty of missing functionality, however in the future it should be more preformant then the VLC backend.

currently works on both windows and linux with osx

needs audio controls. Hwdec is working fine on both windows and linux. and overall perf is improved a good chunk. primarily tested on linux but stability seems fine.

preloading is also an issue right now, since it actually just opens the video and starts playing it... somewhere

alexmercerind commented 1 year ago

package:media_kit is now stable for Windows, Linux, macOS & iOS. Android & Web coming by the end of this month.

drwankingstein commented 1 year ago

I plan on reworking this trying to support the controls added in mediakit when it lands if I can find the time

https://github.com/alexmercerind/media_kit/pull/250

drwankingstein commented 1 year ago

I had a real hard time rebasing this, so the active branch is on https://github.com/drwankingstein/LoliSnatcher_Droid/tree/media-kit-new now instead, so it might not show up here until I force push it over which Ill do when I have the video control bar showing up

alexmercerind commented 1 year ago

It landed :)

drwankingstein commented 1 year ago

I actually have the other branch in a pretty good state so ill force it over tomorrow windows support I would consider Done and excellent. linux on the other hand,

@alexmercerind

I'm hitting two bugs with linux that are rather breaking so they will need addressed first for linux this bug in particular is bad which is pretty significant since we can load and unload 10+ videos within a couple minutes. so ram use is pretty significantly bad. (kinda ironic since it was actually the main motivator T.T).

the second issue is the time it takes to dispose MPV, this isn't really an issue with mediakit persay more or less shared blame, linux audio is really stupid how it's handled, (especially with pipewire since it doesnt even remember audio level) each stream is it's own audio node with it's own volume control and the node doesn't disappear until mpv is terminated, NOT disposed. and mpv termination becomes longer and longer the more you open them up before the last one terminated (starts about 10s after dispose and scales somewhat linearly) all of the duration is taken in the lock. if that can be taken down it will be pretty good, linux memory is a big issue though. (I am forcing pulse audio for now which addresses the volume memory which is fine, and I'll probably do that when I try to merge anyways).

so the only real solution for this issue is to cut way down how long dispose -> terminate takes. I will try to look into the new player.stop() as a work around but im not sure how it will go. (if the issue with memory leak is related to texture unregistering, this may actually help solve that issue too)

other then that, as I said, windows support is excellent, none of the audio issues persist. I do want to try this with osx too since it seems like it will work great there as well. I don't really see me trying to replace the android infran.

well at least on linux, the usability has improved a large chunk on lower end hardware for like, 5-10 videos kekeke

alexmercerind commented 1 year ago

GNU/Linux has some problems at the moment & it's not just package:media_kit but Flutter too. I spent many days trying to find a cause & fix it but nothing worked. The performance on other platforms is significantly higher (with further scope!).

drwankingstein commented 11 months ago

partially blocked on this https://github.com/alexmercerind/media_kit/issues/266

drwankingstein commented 11 months ago

Unfortunately it doesn't seem like it will be possible to use media_kit for this or any other app that requires viewing short videos sequentially, seeing as this wont be possible for use on windows and linux platforms I don't see the point in keeping this open, sorry for wasting the time of anyone who was interested in this

drwankingstein commented 11 months ago

This actually did wind up getting fixed upstream, now there are issues with linux crashing every now and then, but windows is stable and ram usage is fine.

drwankingstein commented 3 months ago

I plan on looking into this more when the GTK4 work lands https://github.com/flutter/engine/pull/50960. I found a lot of my issues to most likely be related to GTK specifically so when this work lands I will rebase this, possibly just redo it entirely.

alexmercerind commented 3 months ago

GTK3 -> GTK4 transition is a major breaking change (& not backwards compatible) from my knowledge / understanding.

Plugins would also require updates to support both GTK 3 & 4 shells differently. A number of things e.g. GL, platform channels & other APIs will be changed. Don't assume it's landing anytime soon, and even if so, all plugin developers to migrate.

To an average user, it doesn't matter either way. + All memory related issues have been resolved in media_kit, specifically GNU/Linux since.

drwankingstein commented 3 months ago

@alexmercerind Regretfully I have other issues, sadly with flutter on linux in general (in which case my usage is very low end devices). Flutter apps are absurdly hard to render in general causing issues on devices with lower end GPUs. (An issue all GDK/GTK3 applications share) GTK4 is a colossal step in the right direction as evidence by the general perf of GTK3 vs GTK4 applications and apps using GDK. And I assume the eventual impeller work will also lead to better graphics performance, but im not holding my breath.

It really is quite absurd how bad it is, Running flutter apps inside of an android emulator can often lead to better performance over running them natively I have noticed.

As an aside, I noticed separate work on a media-kit backend is being done in a branch. Ill close this PR for now regardless in favour of https://github.com/NO-ob/LoliSnatcher_Droid/tree/media_kit_player

@NANI-SORE if you have an list of things needing testing I can test them perfectly fine across a multitude of devices.

NANI-SORE commented 3 months ago

@drwankingstein Thanks, you can already try doing builds on that branch if you want, currently I just need to see if it runs okay on other devices. Otherwise I'll probably publish a test build later in the month in our discord (DM me there or post your discord name here if you are interested and don't have a tester role)