summaryrefslogtreecommitdiffstats
path: root/TOOLS/lua/skip-logo.lua
Commit message (Collapse)AuthorAgeFilesLines
* scripting: don't observe properties with type nilGuido Cella2024-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | mp.observe_property('foo', nil, ...) calls the handler at least 2 times on each playlist change even when the property doesn't change. This is dangerous because if you haven't read observe_property's documentation in a long time this is easy to forget, and you can end up using it for handlers that are computationally expensive or that cause unintended side effects. Therefore, this commit discourages its use more explicitly in the documentation, and replaces its usages in scripts. For console.lua, observing focused with type nil leads to calling mp.osd_message('') when changing file while playing in the terminal with the console disabled. I don't notice issues from this, but it's safer to avoid it. For playlist and track-list this doesn't really matter since they trigger multiple changes on each new file anyway, but changing it can avoid encouraging people to imitate the code. One usage of none in stats.lua is kept because according to b9084dfd47 it is a hack to replicate the deprecated tick event.
* skip-logo.lua: remove lua 5.2 warning messagewm42020-02-291-1/+0
| | | | (OK, I tested it.)
* skip-logo.lua: fix skipping in the first two frameswm42019-10-081-15/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv typically decodes and filters at least 2 frames before starting playback. This happens during seeks, as well as when playback starts from the beginning of the file. skip-logo.lua receives notifications for all filtered frames, even during seeking. It should interrupt during seeking, so as a crude heuristic, it ignored all frames while the player was seeking. This does not mean all these frames are skipped due to seeking (thus it's a "crude hueristic"). In particular, it means that the first 2 frames of a video cannot be skipped, since they're filtered within the playback restart phase (equivalent to "seeking"). Fix this by making the heuristic slightly less crude. Since we observe the property as "none", the property is not actually read until we do it explicitly. By not reading it during seeking, we can let the frames internally queue up (vf_fingerprint discards them in a ringbuffer-like fashion if they're too many). Then, if seeking ends, we get the current playback timestamp, and check queued up frames that are at or after that timestamp. (In some ways, this duplicates what the player's seeking logic does.) A disadvantage is that this is racy. While playback-time is guaranteed to be set when seeking changes from false to true, playback could already have progressed to the next frame (or more) before the script gets time to react. In theory, we could add a seek restart hook or so, but I don't want to. A property that returns the last playback restart time would also do it, but feels to special. Not an important problem in practice anyway.
* video: add vf_fingerprint and a skip-logo scriptwm42019-09-191-0/+245
skip-logo.lua is just what I wanted to have. Explanations are on the top of that file. As usual, all documentation threatens to remove this stuff all the time, since this stuff is just for me, and unlike a normal user I can afford the luxuary of hacking the shit directly into the player. vf_fingerprint is needed to support this script. It needs to scale down video frames as part of its operation. For that, it uses zimg. zimg is much faster than libswscale and generates more correct output. (The filter includes a runtime fallback, but it doesn't even work because libswscale fucks up and can't do YUV->Gray with range adjustment.) Note on the algorithm: seems almost too simple, but was suggested to me. It seems to be pretty effective, although long time experience with false positives is missing. At first I wanted to use dHash [1][2], which is also pretty simple and effective, but might actually be worse than the implemented mechanism. dHash has the advantage that the fingerprint is smaller. But exact matching is too unreliable, and you'd still need to determine the number of different bits for fuzzier comparison. So there wasn't really a reason to use it. [1] https://pypi.org/project/dhash/ [2] http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html