HAvsFunc

[HolyWu]

Originally Posted by Soichiro

Hi, since updating to r33, I get an error "AttributeError: There is no attribute or namespace named dfttest" when trying to use `havsfunc.MCTemporalDenoise`. I was able to use this filter before updating, and I attempted reinstalling dfttest as well. I'm on Arch Linux, Vapoursynth R50.

I don't think your error has anything to do with havsfunc. You can try core.std.BlankClip().dfttest.DFTTest() without using havsfunc at all to make sure.

Did you compile DFTTest from source or install it via distribution package? Is it r6 or r7? What happen if you try the other version?

[Soichiro]

You're right, the example with BlankClip also does not work. I am installing dfttest (and all VS plugins) from the Arch AUR. I've tested with both r6 and r7 of dfttest, and r32 and r33 of muvsfunc. On manually adding a LoadPlugin call, I'm able to get vapoursynth to output the error that it can't find the symbol `fftwf_make_planner_thread_safe`, even though I have fftw installed. (Of course with autoloading, Vapoursynth just silently fails on plugins that have issues...) So, you're right, it does seem like a local machine issue, and not sure how my machine ended up in this state, but that means I'll keep debugging the separate issue. Thanks.

[Soichiro]

It looks like the issue is that, at least on Arch, fftw's pkgconfig files do not include -lfftw3f_threads, which is needed for dfttest to work. So, in case anyone else on Linux runs into the issue, the workaround is to add -lfftw3f_threads to the libs line in /usr/lib/pkgconfig/fftw3f.pc, then rebuild dfttest.

[HolyWu]

Originally Posted by Soichiro

It looks like the issue is that, at least on Arch, fftw's pkgconfig files do not include -lfftw3f_threads, which is needed for dfttest to work. So, in case anyone else on Linux runs into the issue, the workaround is to add -lfftw3f_threads to the libs line in /usr/lib/pkgconfig/fftw3f.pc, then rebuild dfttest.

Ah, I missed that. Updated meson.build accordingly.

[Soichiro]

Thanks! Confirmed that the meson fix in dfttest fixes the issue.

[NullNix]

I finally tracked down the proximate cause of the bug I reported earlier where vapoursynth was generating horrifically chopped-up frames when QTGMC was run over it, at least enough to have a workaround of sorts. As others suggested, the source was at fault, though I still don't quite understand why.

If I use the (makemkv-derived) MKV as the vspipe source, all is well: if I mkvextract the video stream from it and use that (which is what I've been doing without incident for years before now), the chopped-up mess results, even though vspipe is only meant to be using the video stream in any case. I thought video streams were meant to be more-or-less separable from their containers, but this doesn't seem to be true with this one. mpv says that the extracted stream has no timestamps and that ffmpeg is going to make them up, and get them horribly wrong: maybe this is an unusual input, or maybe makemkv's behaviour has changed and it's sticking timestamps in in some unusual fashion now such that mkvextract is no longer cleanly extracting them (one downside of closed-source software is that I can't easily tell which it might be).

So... I guess I'll take my ever-more-obviously catastrophic ignorance on this subject and go away sorry to bother everyone.

[lansing]

Your github readme needs update to show the new functions. I was looking for the overlay function but couldn't find it until I searched for a specific overlay mode.

[lansing]

bug report, I Overlay() a YUV444P16 clip on top of a GRAY16 clip but there's no warning about format mismatch.

clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV444P16)
overlay_clip = core.std.BlankClip(clip_yuv16, color=[0, 220/255*MaxSize16bit, 0])
output_clip = haf.Overlay(clip_yuv16, overlay_clip, mode="lighten")

And here the "lighten" doesn't look right. I compared the result to "lighten" overlay in photoshop and they're so different.

And setting mode="darken" gives a greenish frame.

[poisondeathray]

Originally Posted by lansing

bug report, I Overlay() a YUV444P16 clip on top of a GRAY16 clip but there's no warning about format mismatch.

clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV444P16)
overlay_clip = core.std.BlankClip(clip_yuv16, color=[0, 220/255*MaxSize16bit, 0])
output_clip = haf.Overlay(clip_yuv16, overlay_clip, mode="lighten")

And here the "lighten" doesn't look right. I compared the result to "lighten" overlay in photoshop and they're so different.

And setting mode="darken" gives a greenish frame.

That's not GRAY16 . GRAY16 has 1 channel

Photoshop works in RGB . RGB is an additive color model. You would expect different visual results with blend modes in YUV

[lansing]

Originally Posted by poisondeathray

That's not GRAY16 . GRAY16 has 1 channel

Photoshop works in RGB . RGB is an additive color model. You would expect different visual results with blend modes in YUV

I was reporting three separate issues, the code was referring to the second issue with "lighten" overlay mode.

I just tested with a RGB24 clip overlay on a RGB24 clip, the result matches the one from photoshop. So the Overlay function only works on RGB, it should have a check to restrict it to RGB clips only.

[poisondeathray]

Originally Posted by lansing

I just tested with a RGB24 clip overlay on a RGB24 clip, the result matches the one from photoshop. So the Overlay function only works on RGB, it should have a check to restrict it to RGB clips only.

For some of the other blend modes the math only makes sense to work in RGB.

But in "normal" mode it works ok with other pixel formats . It's used all the time in YUV. Other programs like browsers use YUVA overlays (YUVA444P, YUVA420P) too . It's one of the main benefits of using Overlay in avisynth/vapoursynth or mt_merge . YUV overlays. No additional deterioration from going into RGB back to YUV.

[MythCreator]

A issue about r33. I put CAS.dll under plugin64 folder, but when I use LSFmod, the Editor keep send error code "There is no attribute or namespace named cas"

[ChaosKing]

Sound like cas.dll is not loaded. Try to load it manually and see what error code it shows. std.Loadplugin()

[MythCreator]

Originally Posted by ChaosKing

Sound like cas.dll is not loaded. Try to load it manually and see what error code it shows. std.Loadplugin()

Thanks. std.Loadplugin works fine.

[l00t]

Dear HolyWu,

If you have some spare time, would you be so kind to port InpaintDelogo to VS? I only found DelogoHD available for VS, but making an lgd file is a pain-in-the-a** compared to VoodooFX's automated process...

https://forum.doom9.org/showthread.php?t=176860

Thanks in advance!

[Adub]

InpaintDelogo requires AvsInpaint, which is a Avisynth plugin. So, a manual load of the Avisynth plugin may be required, since there's no native Vapoursynth equivalent. I have no idea if LoadPlugin works for AvsInpaint (it might - I haven't tried), but I'd be a little surprised if HolyWu wanted to add support for a function that requires non-native Vapoursynth plugins.

[lansing]

When running QTGMC, I'm getting a log "AvstpWrapper: cannot find avstp.dll.Usage restricted to single threading" in the console

[Jukus]

Originally Posted by lansing

When running QTGMC, I'm getting a log "AvstpWrapper: cannot find avstp.dll.Usage restricted to single threading" in the console

I don't confirm.

[ChaosKing]

Originally Posted by lansing

When running QTGMC, I'm getting a log "AvstpWrapper: cannot find avstp.dll.Usage restricted to single threading" in the console

Can you show your parameters? I never have seen this message with qtgmc.

[lansing]

Originally Posted by ChaosKing

Can you show your parameters? I never have seen this message with qtgmc.

I was catching this log in the Qt Creator's debug console. I tried all QTGMC presets and they all have this message.