mpv hangs with mvtools vapoursynth script #1168
Comments
|
It hangs because mvtools requests a frame at initialization. Since vf_vapoursynth can deliver frames only after initialization has finished, it's not possible to fix this on mpv's side. |
|
Too bad! |
|
It was a beautiful dream while it lasted :( |
Some VS filters will requests frames from their parent filters while they're initialized. Thy do this in a blocking manner, and initialization will not succeed until the frame request is satisfied. This deadlocked mpv, because we can feed frames to the filter only after initialization is finished. Return an error instead of deadlocking. Note that we (probably) can handle frames being requested during init fine, as long as the requests don't block initialization. But we can distinguish this situation, and a simple test seems to indicate VS usually doesn't do this. See #1168.
|
You still could do something convoluted, like piping vspipe output to mpv. |
|
Some relevant info from the author of the filters:
|
|
For reference, I met similar issue before (#1026). |
|
@wm4 I think there might be workarounds for this issue as well. From the description from the filter author, EDIT: I think I made a mistake. The first few output frames of the filter will probably become dummy as well then, but at least the remaining part of video should be fine. It's ugly but better than deadlock or filter failure from my opinion. |
|
If we feed it dummy frames, we'll also get dummy output. |
|
Yes, I realized that later. But it's only for first few frames. |
|
It'll also happen after seeks. |
|
It's still a workaround, but this could be avoided with customized vapoursynth script, user can append few dummy frame in front, and seek to real part later. |
An attempt at fixing #1168. I see black frames flashing, so it's certainly not perfect.
|
There. Doesn't work overly well, but I suppose it's better than failing completely. |
|
So does this work for you? |
|
It turns out that my laptop is too slow to run this script smoothly(roughly 10fps for a 576p footage), the result looks as expected though(have blank dummy frame in the first ones). I also tried to reduce the blank frames by appending extra frame on the front, but it didn't work. Anyway I don't use mvtools for realtime playback myself. Although I'm interested in @4re's feedback as well. |
|
Sorry for the late reply. I gave a shot at your recommendations and it works! somewhat. Other than that it's great to have it running, thank you guys! |
Uh, not sure. Maybe try playing with the threading suboptions of vf_vapoursynth.
This shouldn't happen. Could be a bug in mpv or the filters you use; hard to tell. |
|
I get the "crashes on seek" too. However it doesn't happen on every seek. The error is: i.e. it crashes from inside vapoursynth. May just be a vs bug... |
|
Actually I'm getting it quite often. |
|
If your source filter calls setFilterError, you're supposed to get a null VSFrameRef* at the other end. I don't think filters are supposed to deal with null VSFrameRef*. |
Not sure if I follow. What else should it return if not a null VSFrameRef*? Though I could make it return dummy frames on EOF. It will probably be a bit slower, but trip up fewer broken filters. |
|
Your source filter, video_in, does need to call setFilterError and return NULL. This NULL is only supposed to appear at the end of the chain, where you call getFrame/getFrameAsync. It should not appear in any of the filters in-between, because the core is not supposed to execute any more filters after setFilterError was called. At least this is how I hope VapourSynth is meant to work. |
It does do that. In the beginning it returned just NULL, but that was fixed some months ago. Anyway, the vapoursynth dev could reproduce this problem outside of mpv. It seems there is a race in error handling. Using |
|
The crashes are gone after vapoursynth/vapoursynth@8ef3b6c |
|
I'm still getting deadlocks with that, and I think a follow-up fix is in work. |
|
I think this should be fully fixed now in vapoursynth git master? |
|
For me everything is fixed, thank you. |
|
Could you PLEASE post the finished script. I've been trying to get frame interpolation happening on GNU/Linux for a week now, this looks to be the beacon of hope I've been searching for. I was just about ready to learn the ffmpeg C library. And this will do frame interpolation right? Right guys? |
|
Just incase that was the finished product I tried your script and got this ┌─[mugi]─[/mpv/mpv-master] fuck.mp4 is that "What The F@#% AMV" by the way, don't judge me. I have an r9 270x if that makes any difference. |
|
Ok I fixed it never mind. |
|
Using OP's script, for some videos I get and with this slightly changed script: I get a bit different error message: |
|
Useless without backtrace... |
|
Using OP's script: Using my script: Let me know if I should compile vapoursynth with debug symbols. |
|
Maybe it's some sort of overflow in the clip length calculation. But I think it must be internal to vapoursynth then. |
|
You can try reducing this number: |
|
Also don't hijack issues with different issues. |
|
num=60, den=1 instead of 60000, 1001 works until this is fixed |
Linux x86_64
nvidia-drivers-343.22
mpv 0.6.0
Vapoursynth Core r24
mvtools from git (https://github.com/dubhater/vapoursynth-mvtools)
Script:
I don't have problems using other vapoursynth filters, just this one.
Also no meaningful output on the terminal, it just hangs.
The text was updated successfully, but these errors were encountered: