Okay, for me, it makes me feel that way :
Topaz Video Enhance AI 2021 modèle dione dv (scintillement sur le mouvement) - YouTube
whereas if the video is deinterlaced and rendered with gaia like here or artemis hight medium proteus etc, I don’t have the flicker effect :
Topaz Video Enhance AI 2021 modèle gaia (pas de scintillement si c’est désentrelacé) - YouTube
I had a similar sounding problem. Unfortunately the digital files I’ve got of the old 8mm film were interlaced (which IMO is just shameful). So running them through the de-interlacer and outputting to ProRes made them very choppy on Windows).
It turns out that they played fine on Mac. So digging deeper, VLC on Windows was the issue - changing the output to OpenGL video output for Windows made them play properly.
Also confirmed these play fine on Davinci Resolve. Hopefully this helps someone else.
I am also experiencing this issue but on nearly every video.
I am trying to improve the quality and upscale a bit some music videos I have that are on DVD. Some are NTSC and others are PAL.
My workflow is the following:
What I find on many of the videos that have any kind of camera panning, it repaints that portion of the screen. The same issue that others have reported.
I have tried importing the .VOB file from the DVD directly into Premiere Pro and exporting as Apple ProRes at the highest quality I could, but it made no difference.
One other note, the issue is introduced after the de-interlace pass, but skipping the de-interlace and going directly to Proteus has the same issue.
Anyone else found a solution for my use case?
I should add that I’ve tried some additional things.
Changed the filename of the .VOB to .MPG and then imported into Apple Compressor as an earlier post recommended and exported the file to Uncompressed 8-bit 422 and then ran the Dione de-interlace, but the issue is still present.
Tried to do the Proteus upscale first and while it doesn’t have the jerky pan issue, it has the interlace lines.
Ran Dione after Proteus and it looks even worse. There are jagged artifacts everywhere.
I am happy to upload a small sample of the video if someone thinks it will help.
Have you tried running it through handbrake to deinterlace and then upsampling that?
Not yet. Do you have any recommended settings for de-interlacing with Handbrake?
I found something that works. Wish that Topaz would improve their de-interlace. Handbrake does a better job and doesn’t break the video.
helo, for me, video enhance is the best for deterlacing 
better than vegas pro, better than handbreak etc… eula, bob etc produce stair effects on some straight lines, even if the video deinterlaces well
Hi all—I’m running into the same problem. In case anybody from support is reading this, I have a reproducible test case where I own the footage, and it is short enough to be easy to check. The source footage was recorded on a Canon 5DmkIII. I’m working with MP4’s straight out of the camera. And I’m seeing the same thing you all are…the source video is 23.976 frames per second. But somehow the Topaz output adds up to 24.01 frames per second (!). This is consistent regardless of AI model, output format (frames or ProRes), and computing platform (tried Intel and Mac M1). I will try recompressing the input video as uncompressed. That is not really practical given the size of my input (I have several thousand clips to process…) but this is a significant problem that really should be investigated as a potential bug in the app.
FWIW, I think it’s possible that the encoding platform (the camera) did something funky. But these videos work properly in all the applications I’ve tested them on…so seeing Topaz treat them differently is very odd to me.
;Chris
Update: transcoding the problem source videos to Uncompressed DOES resolve the issue. It’s not an awesome option (I have thousands of clips to run through…) but it does work. I used Compressor, though I presume pretty much any transcoder would work.
I think for me, this raises a real question: Why would re-encoding to Uncompressed do anything? Isn’t Topaz reading each frame to an uncompressed color space anyway, and inferring the time base from things like the frame rate in the MP4/other movie wrapper? Seems odd to me that simply doing this step separately and handing it to the app would produce a different result, given that I’m not changing frame rate or anything else (at least not in a way that’s visible to me reading file metadata). Then again, the clips that seem most troublesome for me are coming from Magic Lantern software (in other words, not official firmware) on a Canon camera from 2014. No idea whether that firmware was writing proper MP4 files or not.
I’d love to report this as an official bug, as I do have a reproducible error in a test case that doesn’t infringe any copyrights. Any tips on how to do that?
;Chris
