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

Performance? #49

Open
smug opened this issue Jul 20, 2018 · 4 comments
Open

Performance? #49

smug opened this issue Jul 20, 2018 · 4 comments

Comments

@smug
Copy link

smug commented Jul 20, 2018

I enjoy this script a lot however after using it for some time it is undeniable that it has terrible performance problems.
These range from slower initial loading to noticable slowdowns while toggling fullscreen as well as long delays when closing mpv after it was open for some time.
Removing the script immediately fixes all of the problems described above.

Is there a way to address this?

@torque
Copy link
Owner

torque commented Jul 24, 2018

The only thing that springs to the top of my head is that there was a memory leak in libass a while back (3 years ago, apparently) that would cause resource hogging as mpv ran, which would result in performance degradation over time. However, you would have to be using an incredibly old version of libass for this to happen (and I'd expect similar issues to happen with the built-in OSC as well).

I haven't noticed any of the poor performance you describe, but it could be related to a number of factors including your operating system (I'm not sure how different mpv VOs behave when drawing the OSD elements), lua version (I use luajit, and I'd expect PUC-Rio lua 5.[123] to be slightly slower, though not enough to make a noticeable difference), or mpv or progressbar configuration. Lua object garbage collection could be to blame (especially for slowness on shutdown?) but I'm hesitant to pin the blame on it, since I'd expect this sort of problem to be more widespread (or maybe it is and nobody has told me about it). As a side note, do the performance problems seem to happen on all media files you play? For example, a file with a large number of chapters will cause a lot of chapter markers to be created, which are each separate UI elements and therefore take more time to generate and draw than if there are no chapter markers.

I've tried to write this script with performance in mind, and some basic profiling on my part has shown the the UI elements are able to be generated and drawn much more quickly than they currently are. If none of the above information seems to ring any bells, I suppose a good place to start would be by giving me some info about your system and mpv build.

@smug
Copy link
Author

smug commented Jul 28, 2018

I just switched to mpv-x86_64-20180721-git-08a6827 on win7.
I run mpv with:

no-border
no-osd-bar
no-osc

I had considered IO bottlenecks due to slow disk or reading from a network location not sure about that though since it doesn't happen without the script. Freezes during fullscreen/window toggle could be due to expensive redraws of the UI elements. However I don't know how computationally intensive that would need to be to slowdown a current CPU.
It's also strange how it will only happen after watching something for some time. What kind of RAM usage do you experience when watching things while using this script?

@smug
Copy link
Author

smug commented Aug 4, 2018

As neither of us have any idea if this is even a general bug I'll simply close it and just use the normal OSD bar.

@smug smug closed this as completed Aug 4, 2018
@torque
Copy link
Owner

torque commented Aug 7, 2018

I'm going to reopen this because I think it's worth investigating. While I haven't noticed problems under normal use, when running the same mpv instance for a few hours (e.g. playing back several videos from a long playlist), it starts hitching occasionally and complaining about audio/video desync. I haven't determined if this is the progressbar's fault or mpv's fault, but at the very least, I feel like I should do some profiling and garbage collector instrumentation (if I ever stop being too busy to work on this again).

@torque torque reopened this Aug 7, 2018
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

No branches or pull requests

2 participants