Add script-message to allow matching of danmaku by specifying a name

[dyphire]

It can be script-message danmaku-match <name>, This will allow it to be used via commands or called by other scripts , adding extensibility.

[rkscv]

Do you mean manually specifying an episode for videos that match to multiple episodes?

The return value of the dandanplay API for episode matching contains episodeId, animeTitle, episodeTitle, etc., where episodeId uniquely identifies an episode, which can be used for danmaku fetching. We can put the matched episodes in user-data and let other scripts choose one and send script-message danmaku-match <episodeId>.

But how are you going to select the correct episode based on animeTitle and episodeTitle? I find that animeTitle and episodeTitle are sometimes in Chinese and sometimes in Japanese. episodeTitle is mostly in the format of 第N话 标题, but there is also 剧场版. Since the video filenames are mostly in English/romaji, it seems difficult to make accurate matches without using an external database. Or are you going to provide a UI to let users choose?

[dyphire]

Do you mean manually specifying an episode for videos that match to multiple episodes?

This is one of the use cases.

But how are you going to select the correct episode based on animeTitle and episodeTitle? I find that animeTitle and episodeTitle are sometimes in Chinese and sometimes in Japanese. episodeTitle is mostly in the format of 第N话 标题, but there is also 剧场版. Since the video filenames are mostly in English/romaji, it seems difficult to make accurate matches without using an external database. Or are you going to provide a UI to let users choose?

I originally envisioned that It could add danmaku matching support for web streaming video (emby/webdav) by way of script-message, not sure if hash matching would be useful in this scenario.

It's also good to draw an OSD UI for interaction on top of this, which can be provided by the danmaku scripts or implemented by third-party scripts on their own with data from user-data.

[dyphire]

A simple use is for a script to input something like 孤独摇滚 第1话/jojo的奇妙冒险 第3季第12话/紫罗兰永恒花园 剧场版 through mp.input, and then match the bullet screen with the script-message.

On this basis we can just input animeTitle and have the danmaku script draw an OSD UI for selection, or you can return the data via user-data and have the OSD UI drawn by a third-party script.

[rkscv]

not sure if hash matching would be useful in this scenario

Is there any way to get the MD5 sum of the first 16MB of a web streaming video without sending extra requests?

[dyphire]

not sure if hash matching would be useful in this scenario

Is there any way to get the MD5 sum of the first 16MB of a web streaming video without sending extra requests?

There seems to be no reliable way to read the required data from the mpv's cache.

[rkscv]

If you plan to implement the OSD UI or the program for selection yourself, I can implement something like script-message danmaku-match <name> with obtained data storing in user-data and script-message danmaku-fetch <episodeId> for danmaku fetching. Otherwise, I'm inclined to wait for mpv-player/mpv#13982 to be released because I don't want to implement an OSD UI from scratch. uosc is awesome, and I use uosc, but I'm not sure if it's appropriate to rely on a third-party plugin.

[dyphire]

If you plan to implement the OSD UI or the program for selection yourself, I can implement something like script-message danmaku-match <name> with obtained data storing in user-data and script-message danmaku-fetch <episodeId> for danmaku fetching. Otherwise, I'm inclined to wait for mpv-player/mpv#13982 to be released because I don't want to implement an OSD UI from scratch. uosc is awesome, and I use uosc, but I'm not sure if it's appropriate to rely on a third-party plugin.

I think mp.input is handy for input, but drawing the OSD UI using mp.input.select is pretty rudimentary. I prefer to draw the OSD UI base on the scroll-list script.

If you want to provide OSD UI support in your danmaku script then I think using mp.input.select would be more appropriate. Directly provided by the script is probably better as you are more familiar with the dandanplay api.

[rkscv]

The return value of dandanplay API is quite simple. The data in user-data will be like:

[
  {
    "episodeId": 63270001,
    "animeTitle": "化物语",
    "episodeTitle": "第1话 黑仪·蟹 其一",
    "typeDescription": "TV动画"
  }
]

manually specifying an episode for videos that match to multiple episodes

I personally don't encounter this too often.

add danmaku matching support for web streaming video (emby/webdav)

Nor do I currently have a need for it.

I don't plan to implement a third-party script myself in a new repository, and I don't really want to include a Lua script in this repository (the first version of this plugin consists of a Lua script and a C plugin, which I don't think is very elegant). So if you don't plan to implement the OSD UI yourself, let's wait for mp.input.select to be released.

[dyphire]

manually specifying an episode for videos that match to multiple episodes

I personally don't encounter this too often.

I have only encountered this situation when watching some animated movies.

I don't plan to implement a third-party script myself in a new repository, and I don't really want to include a Lua script in this repository (the first version of this plugin consists of a Lua script and a C plugin, which I don't think is very elegant). So if you don't plan to implement the OSD UI yourself, let's wait for mp.input.select to be released.

I originally planned to draw the relevant OSD UI in the load-danmaku script, but I realized that the script entered the content and then obtained the user-data and then entered the content again to achieve the barrage matching, which has multiple script-to-script communication and callbacks in the process.

This may not be very good. It would be much better to have a native implementation based on mp.input.select to provide in danmaku script.

[rkscv]

No way to call Lua scripts directly from the C plugin, need to communicate with console.lua through script-message like input.lua does.

Doing anything in the C plugin is verbose because the libmpv API is quite low level. I wouldn't choose the C plugin if I could send HTTP requests in Lua.

[dyphire]

I'm now thinking that danmaku usage scenarios should use heuristic matching more often, and manually entering matches feels like more of a hassle. Do we have to manually enter matches for every episode? Maybe that could be considered in the future.

Currently it can be implemented first to change to matching danmaku based on media-title when protocol (^%a[%w.+-]-://) playback is detected. As long as the streaming script/tool passes the title name correctly it will match the danmaku. This is much simpler and easier.

[rkscv]

There are always multiple matches when not using hash values. Although the results are sorted by possibility, the one with the highest possibility is not always correct.

[dyphire]

There are always multiple matches when not using hash values. Although the results are sorted by possibility, the one with the highest possibility is not always correct.

For cases where multiple results are returned we can wait for mp.input.select to be released to provide support for selection.

For emby only it returns anime names and episodes in Chinese, which performs much better in terms of matching than Romanization-based name matching.

The episodeTitle of dandanplay exists in both Chinese and Japanese, but after testing, for example, the contents of jojo的奇妙冒险 不灭钻石 第3话 and 化物语 第1话 can be correctly matched with the danmaku. I think this is enough for most emby scenarios. The api I'm testing here is https://api.dandanplay.net/api/v2/search/episodes.

[rkscv]

I've never used Emby. Is the animeTitle episodeTitle format of media-title property your personal config or a common config for Emby?

[dyphire]

I've never used Emby. Is the animeTitle episodeTitle format of media-title property your personal config or a common config for Emby?

My original idea was to add danmaku support for the project of tsukimi, but I noticed the refactoring the developer mentioned there. This makes this implementation unnecessary.