rkscv / danmaku

Danmaku plugin for mpv powered by dandanplay API
MIT License
13 stars 4 forks source link

Possibility of keyword filter support? #9

Closed dyphire closed 4 months ago

rkscv commented 4 months ago

Landed in 4724988.

dyphire commented 4 months ago

Landed in 4724988.

To be honest, this implementation is not very practical. I want something like filter_file = "~~/files/bilibili.json", which supports reading bilibili exported json format file of the filter word. Or read a filter word file in xml format from the more general dandanplay.

rkscv commented 4 months ago

bilibili: Do you mean https://api.bilibili.com/x/dm/filter/user?

dandanplay: The exported XML file uses the same format for rules with the 正则表达式 checkbox checked and unchecked in the UI.

<?xml version="1.0" encoding="utf-8"?>
<filters>
  <item enabled="true">t=123</item>
  <item enabled="true">t=4.+</item>
  <item enabled="true">t=5\d</item>
</filters>
dyphire commented 4 months ago

bilibili: Do you mean https://api.bilibili.com/x/dm/filter/user?

I mean this: image File content example:

[{"type":0,"filter":"援交","opened":true,"id":3505920},{"type":0,"filter":"对不起","opened":true,"id":3505921}]
rkscv commented 4 months ago

Support for filter files exported from bilibili landed in c650e8b.

It takes ~40 ms to filter with ~2000 danmaku and ~1000 rules, perhaps doesn't need something like Aho–Corasick algorithm (increases binary size by ~200KB).

Do you need regex/user based blocking?

dyphire commented 4 months ago

Do you need regex/user based blocking?

Regex matching seems to be necessary. but if this affects performance even further it should not be considered.

The feature of blocking users can be left to the filter option. For example, the filter=userid=bilibili can be used to block specific sources of danmaku (this should allow for runtime updates), for dandanplay other more specific userid blocking is of little use.

rkscv commented 4 months ago

Regex matching seems to be necessary. but if this affects performance even further it should not be considered.

It takes ~40 ms to filter with ~2000 danmaku and ~500 regex rules, increases binary size by ~950 KB. The time spent is not directly proportional to the number of rules, and the time spent is strongly influenced by the content of the rules, so this result may not mean much. I'm not going to introduce this feature if no one really needs it. I don't care much about potential demand, only real demand. According to repository Traffic (Git clones) and Releases assets download count, not too many people are using this plugin.

Edit: Sorry for misunderstanding you if you mean it seems to be necessary for you. It's fine if you don't know if you really need it.

The feature of blocking users can be left to the filter option. For example, the filter=userid=bilibili can be used to block specific sources of danmaku (this should allow for runtime updates)

Open a new issue if you need it.

dandanplay: The exported XML file uses the same format for rules with the 正则表达式 checkbox checked and unchecked in the UI.

Fail to distinguish between regex rules and other rules in the config file, ignore this feature for now.

dyphire commented 4 months ago

Regex matching seems to be necessary. but if this affects performance even further it should not be considered.

It takes ~40 ms to filter with ~2000 danmaku and ~500 regex rules, increases binary size by ~950 KB. The time spent is not directly proportional to the number of rules, and the time spent is strongly influenced by the content of the rules, so this result may not mean much. I'm not going to introduce this feature if no one really needs it. I don't care much about potential demand, only real demand. According to repository Traffic (Git clones) and Releases assets download count, not too many people are using this plugin.

I agree that the cost is not proportional to the added size and functionality. I also don't think it's necessary to implement it.