View Full Version : Best Motion Interpolation's software/plugin ?
Adam65
6th June 2018, 16:05
If you use DirectShow then there are 3 (that I know of) options that can add frame interpolation:
SVP: https://www.svp-team.com/wiki/Main_Page
DmitriRender: http://www.neowin.net/news/the-easiest-way-to-get-60fps-frame-interpolation-playback-using-mpc-hc-mpc-be
MVTools: http://www.tested.com/tech/pcs/329-how-to-enable-motion-interpolation-on-your-movie-files/
I've tried SVP and DmitriRender and found DmitriRender is better for me.
What is your favorite ?
johnmeyer
6th June 2018, 16:21
AFIK, SVP uses the same algorithms as MVTools2 and was created in order to use the GPU for real-time interpolation (so you can get the soap opera effect while watching movies). So, it should give you identical results.
I've used a lot of motion estimation plugins and have found no major differences: they all suffer from the identical problems when they encounter people walking, picket fences, and other well-known torture tests.
The settings are the key to getting the best results. There was a long thread about this about two years ago when someone here tried to get better results and ended up adding some masks to the process. Someone else will have to point you to the thread because I don't have time to look it up. You should definitely try his work.
[edit]I think this is the thread I was trying to remember. You should definitely read it:
SVP-like frame interpolation? (https://forum.doom9.org/showthread.php?t=174410)
ChaosKing
6th June 2018, 16:46
https://forum.doom9.org/showthread.php?t=174793
SVP/Interframe has blurrier results than it should due to a bug (after comparing with MvTools with exact same settings), and FrameRateConverter has superior artifact masking, resulting in overall much better results.
lansing
6th June 2018, 16:50
I just tried DmitriRender, it seems to work better than svp on motions like waving hands.
Adam65
6th June 2018, 22:18
AFIK, SVP uses the same algorithms as MVTools2 and was created in order to use the GPU for real-time interpolation (so you can get the soap opera effect while watching movies). So, it should give you identical results.
I've used a lot of motion estimation plugins and have found no major differences: they all suffer from the identical problems when they encounter people walking, picket fences, and other well-known torture tests.
The settings are the key to getting the best results. There was a long thread about this about two years ago when someone here tried to get better results and ended up adding some masks to the process. Someone else will have to point you to the thread because I don't have time to look it up. You should definitely try his work.
[edit]I think this is the thread I was trying to remember. You should definitely read it:
SVP-like frame interpolation? (https://forum.doom9.org/showthread.php?t=174410)
Thanks for sharing your experience.
https://forum.doom9.org/showthread.php?t=174793
Thanks for the suggestion.
I just tried DmitriRender, it seems to work better than svp on motions like waving hands.
I agree. It feels much smoother.
MysteryX
6th June 2018, 22:28
If you want the best quality, use FrameRateConverter with Preset="slower". It will greatly reduce artifacts by calculating it with 2 different settings, and taking the best areas of each. It does give very superior results than SVP, but is a lot slower and definitely can't be done in real-time.
Sparktank
6th June 2018, 23:17
SVP is very customisable (as-is MVTools), so I mostly use SVP for live-playback with 64-bit versions of everything.
I even replace the avisynth.dll in the SVP installed folder with the latest AVS+ versions.
As long as the main AVS+ is installed and its MVTools updated, you can tweak the (Pro) SVP as much as you like to get results that are satisfactory.
There are some movies I want to convert with FrameRateConverter to compare to SVP's results.
Every movie is different. Very different.
Depending on the style and cinematography, you might get better results than using previous settings.
I'd say there is no guaranteed "blanket" setting that makes everything look decent.
lansing
7th June 2018, 00:53
Here is a comparison between FrameRateConverter and DmitriRender on waving hand. Original frame rate at 23.976fps, rendered at 60fps
FrameRateConverter:
https://i.imgur.com/lbfwrmp.png
DmitriRender:
https://i.imgur.com/uOvz67i.png
Svp gives similar result as FrameRateConverter so I don't bother screenshoting it.
FrameRateConverter just blends the frames, and there's no real frame in between, where with DmitriRender it has real frames along with the interpolated one.
Correction: I double check on the original video, actually there're also no real frames in DmitriRender's sequence, they're all interpolated too.
MysteryX
7th June 2018, 01:06
DmitriRender looks interesting -- hadn't heard of it before.
With FrameRateConverter I have a pretty good algorithm for detecting artifacts but there's just no other backup plan than blending frames in those areas -- definitely open to better ideas.
Does Dmitri have any Avisynth plugin?
johnmeyer
7th June 2018, 01:14
Your comparison is very intriguing. Looks like I have to play around with DmitriRender.
poisondeathray
7th June 2018, 02:04
Correction: I double check on the original video, actually there're also no real frames in DmitriRender's sequence, they're all interpolated too.
Sometimes you don't want to keep original frames; because interpolated frames are always lower in quality and smoother . There can be a flickering / fluctuation especially with higher quality material, or grainy, or noisy material . But sometimes you want to keep some or all original frames. Pros/cons depending on the situation. But resampling all will be smoother, but higher chance of artifacts
There is some discussion on an earlier version of DmitriRender here
https://forum.doom9.org/showthread.php?t=170950
Can you post that waving sample source, and output from DmitriRender, lansing for testing purposes ?
johnmeyer
7th June 2018, 02:21
Interesting thread, Poison, although it went off the rails with people complaining about the activation process. I never did see any useful comparisons (with other ME software), and also didn't see if there is any way to use it other than as a plugin to MPC-HC or other player. For me (and others in this forum), I suspect that they would want it to work as an AVISynth plugin, if possible.
poisondeathray
7th June 2018, 02:27
I haven't tried it, but in theory you can just put together a directshow graph and use it in avisynth that way
The comments weren't convincing me to try it out, but that was an older version too. Which is why I would like to see some results first to see if it's even worth my time
lansing
7th June 2018, 02:47
Here is hand wave sample. The DmitriRender sequence are screenshots from the player.
hand wave sample (http://www.mediafire.com/file/e7msky8l4v1tcrf/hand%20wave.mkv)
MysteryX
7th June 2018, 03:22
Sometimes you don't want to keep original frames
There is an option in FrameRateConverter to use original frames instead of blending. When converting from 15fps to 60fps, however, it causes artifact areas to "stretch" by remaining still while everything else is moving, which gives a very weird effect. However it might not be that bad on 24 or 30fps videos.
Here is hand wave sample.
We can't judge an algorithm based only on a specific scenario. Have to look at how it performs everywhere. But if I could use this in places where I have artifacts to replace, that could be interesting.
johnmeyer
7th June 2018, 05:09
Here is hand wave sample. The DmitriRender sequence are screenshots from the player.
hand wave sample (http://www.mediafire.com/file/e7msky8l4v1tcrf/hand%20wave.mkv)The motion on the hands & fingers does look like some sort of mask/frame blend like what MysteryX did. I looked at lots of freeze frames of the hand wave close ups, and often there were multiple fingers from adjacent frames, but blurred together rather cleverly.
I can't judge the actual motion estimation without being able to do my own tests. The arm movement looks flawless, although there are some artifacts I've never seen before with ME when the arm crosses in front of one of the bright lights. They are really minor and look like small teeth.
poisondeathray
7th June 2018, 05:49
The motion on the hands & fingers does look like some sort of mask/frame blend like what MysteryX did. I looked at lots of freeze frames of the hand wave close ups, and often there were multiple fingers from adjacent frames, but blurred together rather cleverly.
I can't judge the actual motion estimation without being able to do my own tests. The arm movement looks flawless, although there are some artifacts I've never seen before with ME when the arm crosses in front of one of the bright lights. They are really minor and look like small teeth.
What "lots of freeze frames ?" The pictures he uploaded ? He uploaded 5 frames
He only uploaded a source video, not a processed video
lansing - can you make a directshow graph and use avisynth/directshowsource to upload a processed video please?
lansing
7th June 2018, 05:54
lansing - can you make a directshow graph and use avisynth/directshowsource to upload a processed video please?
How do I do that?
poisondeathray
7th June 2018, 05:59
How do I do that?
uhhh, a bit hard to explain.
In graphstudio / graphedit, is there a dimitryrender filter available? (graph => insert filter)
You make a graph with the source filter (actually if you just open the mkv with graphstudio, it will automatically make one. ie. just drag the mkv into the graphstudio window) , but disconnect the renderer. Insert the dimitryrender box right after the decoder box (you probably have lav filters or something) . You might have to connect the pins. Disconnect the audio components. Save the graph with the the renderer disconnected
Create a script referencing the graph, that's it
DirectShowSource("mygraph.grf", fps=23.976, audio=false)
If you can't figure it out, or maybe the dimitryrender box is "locked", then don't worry about it
lansing
7th June 2018, 06:51
I have the graph like this "video->LAV video decoder->dmitrirender->video renderer", it was able to play inside graphstudionext, but when I try to load the grf in avs it said
"DirectShowSource: GRF file does not have a compatible open video pin. Graph must have 1 output pin that will bid RGB24, RGB32, ARGB, YUY2, YV12...."
johnmeyer
7th June 2018, 07:24
What "lots of freeze frames ?" The pictures he uploaded ? He uploaded 5 frames
He only uploaded a source video, not a processed video
lansing - can you make a directshow graph and use avisynth/directshowsource to upload a processed video please?I was looking at the video Lansing provided which is, I assume, the source of the OP's stills.
poisondeathray
7th June 2018, 15:03
I have the graph like this "video->LAV video decoder->dmitrirender->video renderer", it was able to play inside graphstudionext, but when I try to load the grf in avs it said
"DirectShowSource: GRF file does not have a compatible open video pin. Graph must have 1 output pin that will bid RGB24, RGB32, ARGB, YUY2, YV12...."
Disconnect the video renderer (delete the box). Leave the dimitrirender box open as the last box. Save the grf
lansing
7th June 2018, 15:31
Disconnect the video renderer (delete the box). Leave the dimitrirender box open as the last box. Save the grf
Same error message.
poisondeathray
7th June 2018, 15:38
Did you remember to save the new grf ?
Right click the dimitrirender box and see what the output pin is sending , or just right click and see if there are options
lansing
7th June 2018, 16:06
Did you remember to save the new grf ?
Right click the dimitrirender box and see what the output pin is sending , or just right click and see if there are options
https://i.imgur.com/9EKU8O6.png
https://i.imgur.com/tLLHHw8.png
poisondeathray
7th June 2018, 16:16
In directshowsource, specify the pixel_type="NV12" ; if that doesn't work try pixel_type="YUVex"
eg.
DirectShowSource("mygraph.grf", fps=23.976, audio=false, pixel_type="NV12")
lansing
7th June 2018, 17:28
Changing pixel_type to "YUVex" works
DirectShowSource("test.grf", fps=59.94, audio=false, pixel_type="YUVex")
hand wave dmitrirender 60fps (http://www.mediafire.com/file/pqb1a7c4qppybs6/hand_wave_dmitrirender_60fps.mkv)
poisondeathray
7th June 2018, 17:35
Changing pixel_type to "YUVex" works
DirectShowSource("test.grf", fps=59.94, audio=false, pixel_type="YUVex")
hand wave dmitrirender 60fps (http://www.mediafire.com/file/pqb1a7c4qppybs6/hand_wave_dmitrirender_60fps.mkv)
Thanks.
Did you go through it?
There seem to be some problems, duplicate frames, quality issues.... and it doesn't look as "clean" as your screenshots in the hand waving segment. I'm wondering if something got messed up somewhere
If you open the avs in vdub2 or avspmod, go frame by frame, does it look ok or similar to what you see in mpchc frame by frame ?
EDIT: Actually , it does match your screenshots. It's just there are other sorts of problems. Not that impressive on this test video . But I guess for realtime playback it might look a little better than svp or interframe or whatever method on some frames. But other frames are pretty bad. I thought it might be something much better, but it's not really that good overall either ; it fails under the same circumstances as just about everything else in "automatic" mode
lansing
7th June 2018, 17:50
Did you go through it?
There seem to be some problems, duplicate frames, quality issues.... and it doesn't look as "clean" as your screenshots in the hand waving segment. I'm wondering if something got messed up somewhere
If you open the avs in vdub2 or avspmod, go frame by frame, does it look ok or similar to what you see in mpchc frame by frame ?
EDIT: Actually , it does match your screenshots. It's just there are other sorts of problems. Not that impressive on this test video . But I guess for realtime playback it might look a little better than svp or interframe or whatever method. I thought it might be something much better, but it's not really
It took about 3 seconds for the filter to start rendering, so the first 3 seconds of the video doesn't have the effect yet.
Comparing it to framerateConverter frame by frame, dmitrirender is also noticeably blurrier.
johnmeyer
7th June 2018, 18:02
... Not that impressive on this test video . But I guess for realtime playback it might look a little better than svp or interframe or whatever method on some frames. But other frames are pretty bad. I thought it might be something much better, but it's not really that good overall either ; it fails under the same circumstances as just about everything else in "automatic" mode
... Comparing it to framerateConverter frame by frame, dmitrirender is also noticeably blurrier.
Thanks to both of you for taking the time to check this out. Sounds like I can find something else to do and not bother with this. I did notice that the video seemed unusually soft, but I figured that was just the source video itself. It sounds like one of the "tricks" was to add a lot of blur to the video which might make the ME algorithms avoid "blowing up" when tracking sharply defined objects: some of the worst artifacts I ever saw was the rack of antlers on a stuffed moose that was on a float in a parade:
Moose Antlers (https://www.youtube.com/watch?v=t8HjRN0rw5M&t=1m39s)
poisondeathray
7th June 2018, 18:06
It took about 3 seconds for the filter to start rendering, so the first 3 seconds of the video doesn't have the effect yet.
Comparing it to framerateConverter frame by frame, dmitrirender is also noticeably blurrier.
Yes, I would ignore the beginning ...
I wonder if there are any differences between full/registered version (I mean besides the overlay and time for it to start)
By "blurrier" - did you account for compression differences (you used x264 crf23 for dimitri)
BTW, are there any other options? (e.g. can you select different framerates instead of 60.0, quality vs. speed tradeoff, etc...)
For my purposes, I don't really care about a realtime playback filter . I'd rather have a better, higher quality / offline method, even if it's slower or requires some manual input / user guidance. But I'm always looking for something even slightly better for "automatic" interpolation too, because it can be used sometimes as a base layer or compositing fixes
lansing
7th June 2018, 18:31
By "blurrier" - did you account for compression differences (you used x264 crf23 for dimitri)
Oh you're right, the blurriness was caused by the compression, checking the grf in avspmod, the sharpness doesn't change.
I wonder if there are any differences between full/registered version (I mean besides the overlay and time for it to start)
BTW, are there any other options? (e.g. can you select different framerates instead of 60.0, quality vs. speed tradeoff, etc...)
No idea, no options to set custom output frame rate. Maybe we can set it in directshowsource I don't know.
poisondeathray
7th June 2018, 20:31
Are you sure? It does seem "blurrier" to me too ; I know I'm not looking at the crf23 version, but there seems to be more motion blur that you would expect with a plain crf23 encode. Perhaps some motion blur is added to smooth? (that and the re-rendering timing of all subframes)
I think your choice of screenshots was not quite representative, even talking about the arm wave only, let alone other types of motions. It looks pretty bad too in some frames (but you could argue mvtools2 looks worse in some frames, but better in some areas).
Here is dimitry render vs. twixtor with trackpoints. It's not a realtime playback solution; there is some user input into what to track, to help guide the motion estimation
https://s33.postimg.cc/5pkri4swv/dimitrirender_vs._twixtor_trackpt.gif (https://postimages.org/)
But thanks for testing anyway.
MysteryX
7th June 2018, 20:31
In artifact areas, does it give better results than frame blending? Does it leave really ugly artifacts pass through? If it could be used as a backup method instead of frame blending, that could be cool.
poisondeathray
7th June 2018, 20:35
In artifact areas, does it give better results than frame blending? Does it leave really ugly artifacts pass through? If it could be used as a backup method instead of frame blending, that could be cool.
But dimitryrender is a commercial plugin, not open source.
How would you include it in your FrameRateConverter plugin+script ?
Motenai Yoda
7th June 2018, 21:57
so you can get the soap opera effect while watching movies
I think soap opera effect derive by cheap framerate/cadence conversion using something like convertfps, rather than motion interpolation conversion
Here is hand wave sample. The DmitriRender sequence are screenshots from the player.
hand wave sample (http://www.mediafire.com/file/e7msky8l4v1tcrf/hand%20wave.mkv)
I'd like to take a look at this. What's the recommended way to open .mkv videos in Avisynth?
MysteryX
8th June 2018, 00:34
I'd like to take a look at this. What's the recommended way to open .mkv videos in Avisynth?
I just use LWLibavVideoSource for everything and don't have any issue.
johnmeyer
8th June 2018, 01:15
Here is dimitry render vs. twixtor with trackpoints. Which one is on the left? You didn't label them. The one on the left looks like standard ME, so I assume it is Twixtor, but maybe I'm wrong.I think soap opera effect derive by cheap framerate/cadence conversion using something like convertfps, rather than motion interpolation conversionMy Samsung TV creates its soap opera effect using motion estimation.
lansing
8th June 2018, 01:49
Are you sure? It does seem "blurrier" to me too ; I know I'm not looking at the crf23 version, but there seems to be more motion blur that you would expect with a plain crf23 encode. Perhaps some motion blur is added to smooth? (that and the re-rendering timing of all subframes)
I think your choice of screenshots was not quite representative, even talking about the arm wave only, let alone other types of motions. It looks pretty bad too in some frames (but you could argue mvtools2 looks worse in some frames, but better in some areas).
The blurriness I was referring to are the lost of details in the clothing, which was caused by the x264 compression. I'm okay with motion blur on moving objects.
From this example, it should to safe to assume that dmitrirender is better than framerateConverter. Frame blending just doesn't look good on hand waving because on playback, it makes it looking like Matrix.
manolito
8th June 2018, 02:15
From MysteryX
With FrameRateConverter I have a pretty good algorithm for detecting artifacts but there's just no other backup plan than blending frames in those areas
From lansing
Frame blending just doesn't look good on hand waving because on playback, it makes it looking like Matrix.
I believe that these artifacts have nothing to do with falling back to frame blending when artifacts are detected. I ran the source through the old original johnmeyer script from this post
https://forum.doom9.org/showthread.php?p=1800439#post1800439
and the artifacts were identical to the ones caused by FramerateConverter. And the johnmeyer script does not do any frame blending.
Cheers
manolito
poisondeathray
8th June 2018, 02:29
Which one is on the left? You didn't label them. The one on the left looks like standard ME, so I assume it is Twixtor, but maybe I'm wrong.
The order of presentation correlates with the order of text. So, left=dimitri , right=twixtor + track points. Note, that "automatic" or default twixtor looks a lot like mvtools2 results . Sometimes you need a bit of guidance for the motion estimation to make a shot usable.
I believe that these artifacts have nothing to do with falling back to frame blending when artifacts are detected. I ran the source through the old original johnmeyer script from this post
https://forum.doom9.org/showthread.php?p=1800439#post1800439
and the artifacts were identical to the ones caused by FramerateConverter. And the johnmeyer script does not do any frame blending.
I agree, the "blending" is just mvtools2
I also tried ffmpeg minterpolate
https://ffmpeg.org/ffmpeg-filters.html#minterpolate
The default settings, are a lot like mvtools2, and you end up with frame blending, but occlusion and morphing artifacts with the default mode (There are many other settings you can play with, but only had time to play with a few)
And butterflow
https://github.com/dthpham/butterflow
All command line driven (well I guess ffmpeg minterpolate is too... ) but this can use OpenCL . This resulted in almost pure blending, so meh.. but I used the 0.2.4 dev version, not sure if something got broken, I'll revisit 0.2.3 stable when I have time
Blending might be "bad" for realtime playback; but sometimes blobby edge morphing occlusion artifacts are worse. At least blending is consistent. pros/cons
I just use LWLibavVideoSource for everything and don't have any issue.
Thanks, now I just need to figure out which Libav binary distribution to install... do you have recommendation on that? I'm using 32bit AviSynth.
[EDIT] Or should it work without Libav installation? I got
AviSynth open failure:
[Fatal]: Failed to avformat_open_input.
when I tried it.
[EDIT2] I'm dumb. I had the file name wrong. Works perfectly now.
MysteryX
8th June 2018, 23:11
L-SMASH Source (https://forum.doom9.org/showthread.php?t=167435)
I tried John Meyer's frame doubling script with that hand waving video. MediaInfo says
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
so I put 2 times 23.976 as the target frame rate.
For some reason the result doesn't have all the original frames. It goes "out of sync" after frame 55, every frame (or at least most of them) are interpolated after that. Using AssumeFPS doesn't help either. I also tried setting num=48000 and den=1001 but that made it go out of sync slightly faster, after frame 53.
Here's the script I tried, it should display nothing but black if the result has original frames. Can anyone spot an error?
LWLibavVideoSource("d:\process\hand wave.mkv")
orig = last
fps = jm_fps(last, 2*23.976, 32, 2)
orig_only = fps.SelectEven()
#orig_only.AssumeFPS(23.976)
return orig.Subtract(orig_only).Histogram("luma")
# Motion Protected FPS converter script by johnmeyer from Doom9
# Slightly modified interface by manolito
# Requires MVTools V2 and RemoveGrain
# Also needs fftw3.dll in the System32 or SysWOW64 folder for Dct values other than 0
function jm_fps(clip source, float "fps", int "BlkSize", int "Dct") {
fps = default(fps, 25.000)
fps_num = int(fps * 1000)
fps_den = 1000
BlkSize = default(BlkSize, 16)
Dct = default(Dct, 0)
# fps_num = 48000
# fps_den = 1001
prefiltered = RemoveGrain(source, 22)
super = MSuper(source, hpad = 16, vpad = 16, levels = 1, sharp = 1, rfilter = 4) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad = 16, vpad = 16, sharp = 1, rfilter = 4) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize = BlkSize, overlap = 4, search = 3, dct = Dct)
forward = MAnalyse(superfilt, isb = false, blksize = BlkSize, overlap = 4, search = 3, dct = Dct)
forward_re = MRecalculate(super, forward, blksize = 8, overlap = 2, thSAD = 100)
backward_re = MRecalculate(super, backward, blksize = 8, overlap = 2, thSAD = 100)
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)
return out
}
poisondeathray
9th June 2018, 17:02
Here's the script I tried, it should display nothing but black if the result has original frames. Can anyone spot an error?
commment out this line, replace it with fps .
#return orig.Subtract(orig_only).Histogram("luma")
It should be fps, or return fps
orig = last
fps = jm_fps(last, 2*23.976, 32, 2)
orig_only = fps.SelectEven()
#orig_only.AssumeFPS(23.976)
#return orig.Subtract(orig_only).Histogram("luma")
fps
manolito
9th June 2018, 17:16
If you want to double your frame rate and make sure that every other frame will be an original frame then you should edit the johnmeyer script like this:
Before:
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)
return out
After:
out = MFlowFps(source, super, backward_re, forward_re, num = fps_num, den = fps_den, blend = false, ml = 200, mask = 2)
out=out.selectodd()
interleave(source,out)
return last
Cheers
manolito
#return orig.Subtract(orig_only).Histogram("luma")
It should be fps, or return fps
orig = last
fps = jm_fps(last, 2*23.976, 32, 2)
orig_only = fps.SelectEven()
#orig_only.AssumeFPS(23.976)
#return orig.Subtract(orig_only).Histogram("luma")
fps
That's what I tried first, but I noticed the above mentioned problem. This script is just demonstrating the problem clearly, by taking every second frame from the fps clip and comparing it to the original. They should be identical but they're not.
poisondeathray
9th June 2018, 17:21
Oh, I see what you're doing, you're testing it . I get all black, but I'm using FFMS2 . It's probably a source filter issue
FFVideoSource("hand wave.mkv")
poisondeathray
9th June 2018, 17:24
Yes, that's the problem. You ccan check with info()
LWLibavVideoSource returns an off framerate 23.9752 . Probably jitter in the timecodes. Add AssumeFPS(24000,1001). Framecount is correct
Or use FFMS2, which returns 24000/1001
Yes, that's the problem. You ccan check with info()
LWLibavVideoSource returns an off framerate 23.9752 . Probably jitter in the timecodes. Add AssumeFPS(24000,1001). Framecount is correct
Or use FFMS2, which returns 24000/1001
Thanks, using AssumeFPS(24000,1001) fixes it. Or using AssumeFPS(23.976).
I thought it couldn't be a problem with the source because I also converted the mkv to Huffyuv-encoded avi and the problem occurred with that file as well. But obviously the error in framerate just propagated there.
So is FFMS2 better than LWLibavVideoSource in every way?
poisondeathray
9th June 2018, 21:30
So is FFMS2 better than LWLibavVideoSource in every way?
No, sometimes one is preferred over the other for some types of sources. And it depends on the specific version too.
I find you need to have both, and backup plan B,C,D,E
If you want to double your frame rate and make sure that every other frame will be an original frame then you should edit the johnmeyer script like this:
...
That's certainly a way to achieve it, but it seems like it's just covering the real problem which is the incorrect frame rate reported by the source filter. I think the interpolation quality will suffer (perhaps not much, but who knows) when MFlowFps is working with incorrect frame rate.
StainlessS
9th June 2018, 22:57
That's certainly a way to achieve it, but it seems like it's just covering the real problem which is the incorrect frame rate reported by the source filter. I think the interpolation quality will suffer (perhaps not much, but who knows) when MFlowFps is working with incorrect frame rate.
Manolito posted that before it becme clear that you had a source filter problem.
Also, AssumeFPS(24000,1001) is better than AssumeFPS(23.976),
as 24000/1001 is actually 23.97602398.
EDIT: To below,
AssumeFPS(23.976) is an alias for AssumeFPS(24000,1001) in Avisynth 2.57 and up, along with a number of other common framerates.
Thanks Foxy, I had seen in sources, detection and replacment of close to standard common framerates, indeed I do it myself in some scripts.
foxyshadis
10th June 2018, 06:01
Manolito posted that before it becme clear that you had a source filter problem.
Also, AssumeFPS(24000,1001) is better than AssumeFPS(23.976),
as 24000/1001 is actually 23.97602398.
AssumeFPS(23.976) is an alias for AssumeFPS(24000,1001) in Avisynth 2.57 and up, along with a number of other common framerates. Still good practice to use the real fraction in case you need a non-standard framerate, though.
zorr
10th June 2018, 21:48
Manolito posted that before it becme clear that you had a source filter problem.
That's true, I didn't mean to diss his answer. Especially when he was just trying to help me. Sorry Manolito!
Also, AssumeFPS(24000,1001) is better than AssumeFPS(23.976),
as 24000/1001 is actually 23.97602398.
I started to wonder why is it reported as 23.976 (by MediaInfo and even by AviSynth) when that's not what the correct ratio is. Maybe it's because 32bit float can only represent about 7 decimals and the correct ratio needs 8.
StainlessS
10th June 2018, 23:48
and the correct ratio needs 8
Sorry, I just copied from my calculator, no idea how many digits required to accurately represent true result, if indeed it can be expressed in a finite number of digits.
Maybe I should have said something akin to "as 24000/1001 is actually more like 23.97602398."
EDIT: Using WinXP Calculator, Scientific mode, 23.976023976023976023976023976024, 239760 sequence recurring.
Sparktank
11th June 2018, 00:22
Sorry, I just copied from my calculator, no idea how many digits required to accurately represent true result, if indeed it can be expressed in a finite number of digits.
Online calculators (https://www.mathsisfun.com/calculator-precision.html) end up repeating "976023", even if use some unbound decimal points/etc.
23.976023976023976023976023976023etc
StainlessS
11th June 2018, 00:35
Actually sequence starts right at the beginning, ie 239760, etc
Sparktank
11th June 2018, 01:00
:D I see what happened. The coffee cup is always half empty. :devil:
kolak
21st June 2018, 10:34
Time for more modern approach:
https://www.dpreview.com/news/5843863433/nvidia-slow-mo-video-ai
Sparktank
21st June 2018, 17:16
Time for more modern approach:
https://www.dpreview.com/news/5843863433/nvidia-slow-mo-video-ai
I need to get a new NVidia card...
It's not been fun with (and old, legacy) AMD.
I have to use the weakest settings in SVP to enjoy a movie these days if it's going to be 60fps.
Can't wait for cuDNN to become mainstream and someone knocks out an AVS+ or VS plugin.
It would be great to check out how Zack Snyder's movies turn out with this. :)
hydra3333
1st July 2018, 06:53
:) the nvidia link for that AI approach https://news.developer.nvidia.com/transforming-standard-video-into-slow-motion-with-ai/
No clear indication on what it takes (hardware or software) to run the trained neural network.
xKen
28th July 2018, 09:48
:) the nvidia link for that AI approach https://news.developer.nvidia.com/transforming-standard-video-into-slow-motion-with-ai/
No clear indication on what it takes (hardware or software) to run the trained neural network.
"NVIDIA researchers trained the system by processing more than 11,000 videos through NVIDIA Tesla V100 GPUs and a cuDNN-accelerated PyTorch deep learning framework."
hydra3333
28th July 2018, 09:52
Thanks. I wonder how many and how long.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.