Cine-Can this be Made Better?

[Alwyn]

I have a short piece of cine which I am trying to improve. I'm using this AVISynth script and it's coming out OK; hardly any dupes and blends, but I'm wondering if there would be a better script to smooth it out a bit. I have also tried SRestore + RIFE but didn't have much success.

Thanks for any input.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
avisource("F:\Family Videos\Alma Rd.avi")
ConvertToYV12(interlaced=true)
AssumeBFF()
TFM()
Tdecimate(cycle=6,cycleR=1)
Prefetch(24)

[Sharc]

Try

QTGMC(preset="fast")
SRestore(frate=18.0) #deblended 18fps

and interpolated to 50fps

[Alwyn]

Definitely better than my TFM attempt, which has a lot of slightly blended/blurred frames (I still don't understand the Cycle numbers; I know that it's "in XX, take out YY", but how you work out the actual values is still a mystery).

I see though that in your 18fps file, there's 9 dupes, at: 26, 55,66,81,108,121,130,135 and 142. Over 158 frames total, is that normal?

[Sharc]

Reduce frate in SRestore a bit. Try this:

ffms2("Alma Rd snip for VH.avi")

QTGMC(preset="fast")
SRestore(frate=17.5) #returns 17.5fps

# temporal interpolation
RGB=z_ConvertFormat(pixel_type="RGBPS")
RIFE=RGB.RIFE(gpu_thread=1, model=11, fps_num=50000, fps_den=1000, sc=true, sc_threshold=0.3)
YV12=RIFE.z_ConvertFormat(pixel_type="YUV420P8")

return YV12

[Alwyn]

Excellent @Sharc, thank you, nice and smooth. Neat Video did a good job on all the crud, so I'm happy with the result.

[Sharc]

Excellent @Sharc, thank you, nice and smooth. Neat Video did a good job on all the crud, so I'm happy with the result.

Your processing butchered the video again, introducing new temporal an spatial inconsistencies (jerky timeline and vertical jumping).

Edit:
If you want to clean it up a bit better use an Avisynth filter:

[Alwyn]

Your processing butchered the video again, introducing new temporal an spatial inconsistencies (jerky timeline and vertical jumping).

RIFE is causing the jumping. Watch the bottom black bar.

Apart from the jumping, I don't think yours is much better than mine. What's your code?

[Sharc]

Your processing butchered the video again, introducing new temporal an spatial inconsistencies (jerky timeline and vertical jumping).

RIFE is causing the jumping. Watch the bottom black bar.

Apart from the jumping, I don't think yours is much better than mine. What's your code?

Your NeatVideo version in post#5 was horribly jumpy and jerky. No idea how this came.
Code has been given in post#4. It doesn't jump and jerk like your NeatVideo sample, nor like your latest RIPE sample which is still more jumpy for whatever reason. Download latest RIPE and use model 11 as per post#4. There might be even better options/solutions. I didn't try long.
The file 50fps_2.mp4 in my post#6 used exactly the same code just followed by some denoising filter to reduce the film speckles.

[Alwyn]

Come on mate, can't you see I trying to learn here? What is the point of replying:

just followed by some denoising filter to reduce the film speckles.

when I ask you for your code?

[Sharc]

Come on mate, can't you see I trying to learn here? What is the point of replying:

just followed by some denoising filter to reduce the film speckles.

The point is as per your statement:

Apart from the jumping, I don't think yours is much better than mine

You got the code in post #4 which doesn't produce the jumping, and as you didn't see anything "much better", why bother?
So here the Spotless script to mitigate the speckles, or use any of the similar filters which are shipped with Hybrid:

/*
    SpotLess v1.07. temporal spot/noise remover, by StainlessS @ Doom9.   https://forum.doom9.org/showthread.php?t=181777
    Original idea from Didée post :-                                      https://forum.doom9.org/showthread.php?p=1402690#post1402690
    Req:- Pinterf MvTools2(), Pinterf Medianblur2() with MedianBlurTemporal rather than the MedianBlurT() from Didée post.
          With appropriate plugins, will be AVS+ colorspace and x64 compatible.
          Fine using Avs+ Prefetch() so long as current Pinterf plugins, and Frame Accurate source. RequestLinear() following the source filter might suffice as frame accurate source filter.

    NOT FOR cartoon/anime, live video only, sorry.

    v1.01, Remove RadT Max check. Add MSuper(hpad=16,vpad=16). Add BlkSz arg.
    v1.02, Add some stuff.
    v1.03, Frame size auto config of args removed (found instances where caused problems). Added Glob and bBlur args.
    v1.04, Script breaking changes, I guess is more flexible if can also set ThSAD, inserted ThSAD 3rd arg. RadT now default 1, was 2, dont over denoise unless requested.
    v1.05, Additional checks on args.
    v1.06, Glob Default true, Almost always better.
    v1.07, bBlur Default changed from 0.0 OFF, to 0.3, slower but better for mc analysis. Maybe try 0.6 for HD to overcome HD 'grittiness'.
               ThSAD default changed from 10,000 to 255 * (8/2 * 8/2), ie 1/4 of 8x8 block at 255, ie 1/4 BlkSz spots @ max SAD. Also ThSAD2 a bit less than ThSAD.
               Added dc arg, detect clip.

    SpotLess(clip c,int "RadT"=1,int "ThSAD"=255*(8/2 * 8/2),int "ThSAD2"=ThSAD-(8*8),int "pel"=2,bool "chroma"=true, int "BlkSz"=8,Int "Olap"=BlkSz/2,
            \ bool "tm"=true,Bool "glob"=True,Float "bBlur"=0.3, clip "dc"=Undefined)

    RadT, 1 or more, Default 1. Removes Spots on up to RadT [Temporal Radius] consecutive frames.
        RadT > 2 will usually be overkill. Setting too high could possibly result in blurring.
        Each pixel in result frame is median pixel value of (2*RadT+1) motion compensated frames (including source, ie current_frame-RadT to current_frame+RadT).

    ThSAD, Default 255 * (8/2 * 8/2) ie 4080 <ie 1/4 of 8x8 block at 255, ie 1/4 BlkSz spots @ max SAD>.
        0 < ThSAD < 16320(8*8*255). 8x8 block SAD threshold at radius 1 (ie at current_frame +- 1) [SAD, Sum of Absolute (pixelwise) Differences].
        ThSAD and ThSAD2 suggested absolute minimum of maybe about 400.
        ThSAD and ThSAD2 thresholds are based on 8 bit 8x8 block, irrespective of colorspace depth or BlkSz, max=8x8x255=16320, use same thresholds where High Bit Depth.
        In mvTools MCompensate(), when creating a compensated block the SAD between compensated block and the same original block in current_frame, the 8 bit SAD is measured and if
        greater than SAD threshold then that block is ignored and uses original block from current frame instead. [The compensated block is judged too different, so ignored & original block used instead
        in the result MCompensated frame].
        Where eg ThSAD=64, AVERAGE absolute single pixel difference threshold would be 64/(8*8)=1, so AVERAGE absolute pixel difference greater than 1 would ignore that mcompensated block and use the
        block from current frame in the resulting mcompensated frame instead. This example allows for all pixels in a 8x8 block to be different by 1, or a single pixel in 8x8 block to be different by 64,
        or some other mixture.
          A problem with above is, if a low ThSAD and current_frame block is mostly noise, so compensated blocks could be judged bad because they are too different to the bad noisey block, and the result
        block may/will be just as bad as the noisy source block. A possible solution to this problem is to have a higher SAD threshold and/or have a bigger BlkSize so that the number of bad source pixels
        after converting/scaling to as if an 8x8 block, will contain fewer bad noise pixels. So, SpotLess BlkSz arg would ideally maybe 4 or more times the area of the largest spots that you have, and a SAD
        threshold big enough so as to not ignore the block [ wild guess minimum SAD threshold for big spot sizes of (8x8x255)/4 = 4080 ].
        Where a complete source frame is bad, then maybe should have very high (eg 10000) SAD threshold, and BlkSz may not really matter too much.
          It is not the end of the world if some of the compensated blocks are ignored and swapped for the original current_frame block. Nor is it the end of the world if
        no blocks were ignored because of high SAD threshold. The final result pixel is median pixel value of (2*RadT+1) motion compensated blocks, so allowing for some mistakes by choosing the
        middle pixel value.
        I've just tested real bad double frame, full frame luma and chroma corruption, with below line:
            SpotLess(RadT=5,ThSAD=1000000,ThSAD2=1000000,pel=2,chroma=false,BlkSz=8,Olap=4,tm=false,glob=false,bBlur=0.0)
        And although both SAD thresholds of 1 million, are totally impossible and so no blocks could possibly be ignored and yet we still got pretty good results, all frames were fixed
        as we still had the temporal median filter to fall back on and pick the middle pixel value.

        From mvtools2 docs:
          ThSAD is SAD threshold for safe (dummy) compensation.
              If block SAD is above the thSAD, the block is bad, and we use source block instead of the compensated block. Default is 10000 (practically disabled).

    ThSAD2, Default ThSAD-(8*8), 0 < ThSAD2 <= ThSAD < 16320(8*8*255), Lower removes fewer spots, but less chance of blurring.
        ThSAD2 sets the SAD [Sum of Absolute Differences] threshold for most distant frame from current_frame at distance RadT, with those frames that are distances in-between 1 and RadT
        acquiring a SAD threshold linearly interpolated between the two.
        From mvtools2 docs:
          ThSAD2:
              Defines the SAD soft threshold for the furthest frames at current_frame +- RadT.
              The actual SAD threshold for each reference frame is a smooth interpolation between the original thSAD (close to the current frame)
              and thSAD2. Setting thSAD2 lower than thSAD allows large temporal radii and good compensation for low SAD blocks while reducing the global error and the
              risk of bluring when the result of MCompensate is passed to a temporal denoising filter.
        EDIT: Although I have said that SAD threshold being too high could result in blurred frames, that is really taken from above "risk of bluring" line from mvtools docs,
        however, that warning says "temporal denoising filter", which might suggest pixel averaging, whereas we are using pixel median. I'm not sure that blurring would be the result
        of having too high a SAD threshold.

    Pel,     Default 2. 1, 2, or 4. Maybe set 1 for HD+. (1=precision to pixel, 2=half pixel, 4=quarter pixel)

    Chroma,  Default True. MAnalyse chroma arg. If true, use chroma in block matching when creating vectors. Maybe use False if source B&W or color noise.

    BlkSz,   Default 8. MAnalyse BlkSize. Bigger blksz quicker and perhaps better for HD clips. [Info: current Pinterf MvTools allows for BlkSize=12, and overlap=6]

    OLap,    Default half BlkSz, Block overlap.

    Tm,      TrueMotion Default True. Some folk swear truemotion=false is better.

    Glob,    Default True (True v1.06, was same as Tm, true almost always better), Allow set MAnalyse(global) independently of TrueMotion.
             From MvTools2 docs for MAnalyse,
               global
                 Estimate global motion (at every level) and use it as an additional predictor.
                 Only pan shift is estimated (no zoom and rotation).
                 Use false to disable, use true to enable.

    bBlur,   Default 0.3. If used, Suggest about 0.3, where MAnalyse create vectors is performed on denoised (blurred) super clip
             for better motion analysis. Maybe try 0.6 for HD clip to counteract HD 'grittiness'. bBlur ignored if dc clip specified,
             If providing bBlur, then ALWAYS specify as named argument ie bBlur=bBlur, we will likely insert any additional MvTools args
             before bBlur to keep them together.

    dc,      Default UnDefined. If dc Specified, then must be same size and colorspace as source clip.
             If detection clip specified then bBlur prefilter arg is ignored, and analysis is performed on
             dc.MSuper() clip [ instead of c.Blur(bBlur).MSuper() ]. Allows to provide your own prefiltered clip.
             If providing dc clip, then ALWAYS specify as named argument ie dc=DC, we will likely insert any additional MvTools args
             before bBlur to keep them together.

*/

Function SpotLess(clip c,int "RadT",int "ThSAD",int "ThSAD2",int "pel",bool "chroma", int "BlkSz",Int "Olap",bool "tm",Bool "glob",
    \ Float "bBlur", clip "dc" ) {
    myName   = "SpotLess: "
    RadT     = Default(RadT,1)                 # Temporal radius. (MCompensate arg)
    ThSAD    = Default(ThSAD,255*(8/2 * 8/2))  # SAD threshold at radius 1. Here is max'ed out at 255 * 1/4 of 8*8 block <ie 4080> (MvTools Default 10,000 is nearly OFF, maybe way Too High).
                                               #     Maybe above 255*8/2*8/2 still a bit high, maybe 128*(8/2 * 8/2) Better <ie 2048>. For General noise perhaps somethimg like 24 * (8 * 8) <ie 1536>.
    ThSAD2   = Default(ThSAD2,ThSAD-(8*8))     # SAD threshold at radius RadT(a bit less than ThSAD).
    Pel      = Default(pel,2)                  # Default 2. 1, 2, or 4. Maybe set 1 for HD+. (1=precision to pixel, 2=precision to half pixel, 4=quarter pixel)
    Chroma   = Default(chroma,True)            # MAnalyse chroma arg. If set to true, use chroma in block matching.
    BlkSz    = Default(BlkSz,8)                # Default 8. MAnalyse BlkSize. Bigger blksz quicker and perhaps better, esp for HD clips. Maybe also better where BIG noise.
    OLap     = Default(OLap, BlkSz/2)          # Default half of BlkSz.
    Tm       = Default(tm,True)                # TrueMotion, Some folk swear MAnalyse(truemotion=false) is better.
    Glob     = Default(glob,True)              # Default True, Allow set MAnalyse(global) independently of TrueMotion.
    bBlur    = Default(bblur,0.3)              # Default 0.3. Suggest about 0.3 for better motion analysis, but a bit slower.
    HasDC    = dc.Defined                      # bblur ignored if HasDC, ie user already provided prefiltered clip.
    Assert(1 <= RadT,myName + " 1 <= RadT")
    Assert(0.0 <= bblur <= 1.58, myName + "0.0 <= bblur <= 1.58")
    Assert(pel==1 || pel==2 || pel==4, myName + "pel==1 || pel==2 || pel==4")
    pad = max(BlkSz,8)
    sup = (HasDC ? dc : bBlur>0.0  ? c.blur(bBlur) : c ).MSuper(hpad=pad,vpad=pad,pel=pel, sharp=2)
    # Only 1 Level required where not MAnalyse-ing.
    sup_rend = (HasDC||bBlur>0.0) ? c.MSuper(hpad=pad,vpad=pad,pel=pel, sharp=2,Levels=1) : sup
    MultiVec = sup.MAnalyse(multi=true, delta=RadT,blksize=BlkSz,overlap=OLap,chroma=Chroma,truemotion=Tm,global=Glob)
    c.MCompensate(sup_rend, MultiVec, tr=RadT, thSad=ThSAD, thSad2=ThSAD2)
    MedianBlurTemporal(radiusY=0,radiusU=0,radiusV=0,temporalradius=RadT)  # Temporal median blur only [not spatial]
    SelectEvery(RadT*2+1,RadT)                                             # Return middle frame
}

[lollo]

Sharc, you should also give to Alwin the parameters you used for Spotless . In the wrong hands it can cause disasters!

Alwin, if you are serious about removal defecst, you can find nice examples in this thread https://forum.doom9.org/showthread.php?p=1944703#post1944703, were Spotless is used in combination with Delta Restore mask; johnmeyer can help a lot here!

[Sharc]

Sharc, you should also give to Alwin the parameters you used for Spotless . In the wrong hands it can cause disasters!

Absolutely. One reason why I absteened from promoting the script in a first instance, focusing on the motion fluidity instead.
Anyway, if I remember correctly I used for my quickshot RadT=3, ThSAD=2000. Rest left at defaults. No attempts for 'optimization'.

Alwin, if you are serious about removal defecst, you can find nice examples in this thread https://forum.doom9.org/showthread.php?p=1944703#post1944703, were Spotless is used in combination with Delta Restore mask; johnmeyer can help a lot here!

Yep, some homework for Alwyn

[johnmeyer]

Alwin, if you are serious about removal defecst, you can find nice examples in this thread https://forum.doom9.org/showthread.php?p=1944703#post1944703, were Spotless is used in combination with Delta Restore mask; johnmeyer can help a lot here!

I did look at the original post as well as the film clip and have been lurking since then.

The OP never said what sort of transfer system produced this mess or whether processing was done before it arrived in his hands. Obviously it is silent amateur film and had some sort of processing to bring it from 16 or 18 fps (the most common amateur film speeds) to 25 fps. However, the equation for recovering the original frames is not as simple as taking ratios between 25 and either 16 or 18 because, depending on what capture system was used, that capture system can run at any speed it feels like and, if the capture was simply done by pointing a PAL camera at the screen, you can get any arbitrary number of duplicate and/or blended fields or frames.

The proper way to IVTC this is to first separate it into fields using either SeparateFields() or a Bob filter. Then start counting carefully to see how many unique fields you have compared to how many total fields you count. That will give you the Cycle and CycleR parameters. If you set up TFM and TDecimate correctly, I don't think you need SRestore with this particular clip.

As for Spotless, both that filter as well as the older RemoveDirtMC(), which I still use sometimes, can work wonders with the dirt. You really don't want to be degraining this until you first remove the dirt.

As for Neat video, I have never been a big fan, and would certainly not use it for this project. It tends to remove a lot of detail and softens the video a lot. First-time restorers are often attracted to it because it does indeed kill all the noise, and they often haven't learned how to look for, and to appreciate all the details that have vanished. They are just so happy to see that darned noise disappear that they think the result is wonderful.

Eventually they learn, but often not until they've spent a lot of time ruining a lot of good footage.

I don't have the time to do the work I described above, but it shouldn't take more than 5-10 minutes to count the fields and then set up TFM and TDecimate to give you a clean clip. You MUST have a near-perfect (no blends or dups) clip before you can feed that to any dirt removal or denoiser (including NEAT).

As always, if you want to learn how to get great results when restoring film transfers, head over to doom9.org and read the three posts started by "VideoFred." To give you incentive to do that, here are the results he posted 14 years ago. His technique and the tools he has posted have only gotten better since then. Prepare to be amazed:

https://vimeo.com/13173031

[lollo]

The proper way to IVTC this is to first separate it into fields using either SeparateFields() or a Bob filter. Then start counting carefully to see how many unique fields you have compared to how many total fields you count. That will give you the Cycle and CycleR parameters. If you set up TFM and TDecimate correctly, I don't think you need SRestore with this particular clip.

Nice guideline, thanks John!

As for Spotless, both that filter as well as the older RemoveDirtMC(), which I still use sometimes, can work wonders with the dirt. You really don't want to be degraining this until you first remove the dirt.

Yes, we always reccomend remove dirt first then denoise, in that exact order.

As for Neat video, I have never been a big fan, and would certainly not use it for this project. It tends to remove a lot of detail and softens the video a lot. First-time restorers are often attracted to it because it does indeed kill all the noise, and they often haven't learned how to look for, and to appreciate all the details that have vanished. They are just so happy to see that darned noise disappear that they think the result is wonderful.

There is nothing NeatVideo can do than cannot be beaten by AviSynth, as we always said

As always, if you want to learn how to get great results when restoring film transfers, head over to doom9.org and read the three posts started by "VideoFred." To give you incentive to do that, here are the results he posted 14 years ago. His technique and the tools he has posted have only gotten better since then. Prepare to be amazed:

https://vimeo.com/13173031

I would also add the wonderful results obtained with upscaling: https://forum.doom9.org/showthread.php?p=1810955#post1810955 (to other readers: this is for films)

[johnmeyer]

I did have a moment to "walk through" the video. I bobbed it and then counted the number of unique frames. I didn't got through the entire clip, but I got 50 unique frames in the first 141 fields. If there were no duplicates or blends I should get 50 unique frames in only 100 fields (i.e., two fields per frame).

I may have a few minutes this afternoon and I'll see if I can get a good, clean result just using TFM/TDecimate. SRestore is a nifty script, but it will not produce as clean a result as TFM/TDecimnate, if that IVTC tool can do the job. SRestore should only be used when you have residual blends.

[johnmeyer]

I re-did the counting and came up with 50 and 144. I then used this script to recover the original frames.

loadPlugin("E:\Documents\My Videos\AVISynth\AVISynth Plugins\plugins\TIVTC.dll")
AVISource("E:\Documents\Dnload\UNPACK\Alma Rd snip for VH (DV).avi").killaudio()
AssumeBFF()
tfm(display=false,mode=4,pp=3,cthresh=255)  
tdecimate(display=false,mode=0,cycleR=44,cycle=144)

I then fed that into my film restoration script which I've posted over at doom9.org. I have the option to either use RemoveDirtMC or Spotless, but for some reason I couldn't get Spotless to work well on this. In addition, I had to use an insanely large dirt removal number to make it work. I didn't have time to figure out what was going on. If you click on the link below, you'll see the result of that effort. If I had time I could improve it quite a bit, but I think it shows how proper dirt removal, stabilization, and sharpening can help improve the film transfer.

https://www.mediafire.com/file/csb1ju99gn63h94/FilmScriptRestoreAfterIVTC.avi/file

[Alwyn]

Thanks very much, John, before you posted that I came up with 29 to be removed in 51, which results in a much jerkier vid than yours.

Would I be right in saying that the categorisation of a frame as "unique" is a bit subjective?

The TFM and TDecimate parameters are obviously having a big effect as well, so I'll look at those.

[johnmeyer]

Thanks very much, John, before you posted that I came up with 29 to be removed in 51, which results in a much jerkier vid than yours.

Yeah, 29 out of 51 is way too many and you will end up with jerky frames.

Follow the procedure I outlined in my first post above in order to get the best number. You will be looking at fields, not frames. To make sure you are counting real fields and not blends, only add a finger (I use fingers to count) when you see movement. The dirt spots make it really easy to tell if you are looking at a new field. If you see a big blob of dirt, only add a finger when that dirt completely disappears.

To make the process as easy as possible, try to find a clip where you have as much movement as possible. The clip you provided is actually pretty good because it has a continuous pan so it is fairly easy to tell when you have gotten to the next frame.

[edit]Also remember that when you look at the video I posted, you will now be aware of "judder" which is the jumping effect that happens when slow-fps film or video is panned. That judder was obscured by all the blends and jumping in the original video. Judder is actually an effect which happens in your head because the frame rate is well below your persistence of vision. If you walk through the video frame-by-frame, you will not see any jumping.

[Alwyn]

To confirm, does CycleR include blends and dupes?

[johnmeyer]

Don't even think about blends, dups, clean frames, or anything else. Just count the number of unique frames (but do it with fields!!) and then look at how many times you have advanced the video. [edit] If you get the TFM parameters set correctly, it will take care of matching the good fields and discarding the blends.

[Sharc]

[edit]Also remember that when you look at the video I posted, you will now be aware of "judder" which is the jumping effect that happens when slow-fps film or video is panned. That judder was obscured by all the blends and jumping in the original video. Judder is actually an effect which happens in your head because the frame rate is well below your persistence of vision. If you walk through the video frame-by-frame, you will not see any jumping.

FWIW here a temporal interpolated variant (using RIFE, settings as in post#4) of the IVTCed restoration, for those who prefer the (soap opera) video look. The interpolation artifacts are acceptable in this case/for this scene, I think.

[johnmeyer]

FWIW here a temporal interpolated variant (using RIFE, settings as in post#4) of the IVTCed restoration, for those who prefer the (soap opera) video look. The interpolation artifacts are acceptable in this case/for this scene, I think.

Yes, motion flow works perfectly for pan shots and any other video where everything in the scene is moving in unison. The interpolated frames look just as good as the original frames.

However, the residual dirt that my dirt removal algorithm missed does look worse because it now persists into the interpolated frames.

[Gelinox]

And without Avisynth ?

[johnmeyer]

And without Avisynth ?

Very nice.

I also love the mystery of not telling anyone how you did it.

[Alwyn]

...

[Sharc]

And without Avisynth ?

Very nice.

I also love the mystery of not telling anyone how you did it.

Reminds me on the FILM9 project/discussion/debate ....
https://forum.videohelp.com/threads/369010-FILM9-Restoration-software-for-old-films-%2...m%29-and-video

Still availabe from here:
https://forum.videohelp.com/threads/369010-FILM9-Restoration-software-for-old-films-(8...22#post2666306

[Alwyn]

Thanks to all who participated in this. I've learnt a lot.

I think I'll go with John's TFM (I modified the Cycles a bit), with Framerateconverter at 25fps to smooth things out a bit. I've denoised with default Neat Video settings. I think it looks "authentic" .

SetFilterMTMode("DEFAULT_MT_MODE", 2)
AVISource("F:VH\Alma Rd snip for VH.avi").killaudio()
AssumeBFF()
tfm(display=false,mode=4,pp=2,cthresh=255)  
tdecimate(display=false,mode=0,cycleR=29,cycle=100)

FrameRateConverter(NewNum=25, NewDen=1, Preset="normal")

Prefetch(24)

RIFE has a bit too much jello eg along the roof line.

[Sharc]

Thanks to all who participated in this. I've learnt a lot.

I think I'll go with John's TFM (I modified the Cycles a bit), with Framerateconverter at 25fps to smooth things out a bit. I've denoised with default Neat Video settings. I think it looks "authentic" .

SetFilterMTMode("DEFAULT_MT_MODE", 2)
AVISource("F:VH\Alma Rd snip for VH.avi").killaudio()
AssumeBFF()
tfm(display=false,mode=4,pp=2,cthresh=255)  
tdecimate(display=false,mode=0,cycleR=29,cycle=100)

FrameRateConverter(NewNum=25, NewDen=1, Preset="normal")

Prefetch(24)

RIFE has a bit too much jello eg along the roof line.

ok, but did you notice the jumps in the left-bottom corner? I don't know in which phase of the processing (IVTC, Neat, interpolation) these artifacts sneaked in.
Also remember that this steady-motion panning scene is not very demanding for motion interpolation. I would check and compare the tools for more demanding scenes as well.

[Alwyn]

Wandering brain... I thought I'd apply Mercalli 6 SAL to a couple of different techniques used on the Alma Rd file in post #1. I like the TFM/Framerateconverter version.