Deinterlacing advice

[poisondeathray]

Originally Posted by flossy_cake

With TDecimate I am able to convert it to a 60p stream containing 30p @ 2:2 and 24p @ 3:3:2:2 like so:

ChangeFPS(120000,1001)  
TDecimate(mode=1,hybrid=0,cycle=4,cycleR=2,vidThresh=1.1,display=true)

The result is "ok". Certainly better than 1:1:1:2 @ 30fps but not quite as smooth as 3:2 @ 60fps. Still dissatisfied & I'm trying to add a second pass of TDecimate to smooth the 3:3:2:2 section without affecting the 2:2 section.

If the primary concern is "smoothness", how about retiming using optical flow or equivalent for interpolation of "in between" frames?

RIFE is in avisynth now ( not just vapoursynth) and it tends to do a cleaner, better job than mvtools2 on most content.

a) retiming the 1st part to 29.97p ? Smooth, no judder.

b) Or if you don't like the 29.97 "look", retime 29.97p stairs section to 23.976p ? ie. leave the entire thing at 3:2 to keep the judder consistent like a normal film

c) or the 59.94 "soap opera" look ?

rife@29.97
https://www.mediafire.com/file/mgy52...29.97.mkv/file

rife@23.976
https://www.mediafire.com/file/33qpj...3.976.mkv/file

rife@59.94
https://www.mediafire.com/file/hfgt7...59.94.mkv/file

Rife 4+ models allow for arbitrary framerates, but <4 can only produce powers of 2 (so you have to call them multiple times and selectevery, or use other interpolation at 2nd step) . The best model overall is 2.3 or 2.4 on most content, but models 4+ are faster and are easier to use because of the fpsnum / fpsden . Interpolation is not perfect, there can be artifacts, and you have to manually identify the sections with trim()

[Katie Boundary]

Originally Posted by flossy_cake

The indoor scenes were shot on 1970s video cameras

Jesus, the first season was made in literally the same year in which the first Betamax devices were released in Japan. How cutting-edge they must have thought they were being

I think any reasonable solution to this issue would require ripping the episodes from DVD, not Blu-Ray.

[hello_hello]

Originally Posted by Katie Boundary

Jesus, the first season was made in literally the same year in which the first Betamax devices were released in Japan. How cutting-edge they must have thought they were being

Video tape has been used since the late 50's.
https://en.wikipedia.org/wiki/Videotape#Broadcast_video

Originally Posted by Katie Boundary

I think any reasonable solution to this issue would require ripping the episodes from DVD, not Blu-Ray.

The Bluray version looks better.

[flossy_cake]

Originally Posted by hello_hello

I went with the assumption the difference was the same as the difference between a generic and ITU/mpeg4 aspect ratio for DVDs and it seemed to work out that way. So....

(15/11) / (4/3) = 1.0227

I recognise that number -- it's also the diff between 704 and 720 width: 704 * 1.0227 = 720. Could be a coincidence though, I don't really know.

[flossy_cake]

Originally Posted by poisondeathray

If the primary concern is "smoothness", how about retiming using optical flow or equivalent for interpolation of "in between" frames?

RIFE is in avisynth now ( not just vapoursynth) and it tends to do a cleaner, better job than mvtools2 on most content.

a) retiming the 1st part to 29.97p ? Smooth, no judder.

b) Or if you don't like the 29.97 "look", retime 29.97p stairs section to 23.976p ? ie. leave the entire thing at 3:2 to keep the judder consistent like a normal film

c) or the 59.94 "soap opera" look ?

rife@29.97
https://www.mediafire.com/file/mgy52...29.97.mkv/file

rife@23.976
https://www.mediafire.com/file/33qpj...3.976.mkv/file

rife@59.94
https://www.mediafire.com/file/hfgt7...59.94.mkv/file

That's awesome, I can't even see any blended frames. The question is, can it be done in realtime, i.e opening .avs file directly in MPC-HC? If not, then I'd have to transcode which means generation loss. But maybe it's worth it.

It's really weird with that show Oz cause they always switched to 30fps for locations whenever there are CRT monitors in the scene. I figured it's something to do with syncing to the 60hz of the CRTs for anti flicker reasons. I seem to recall the TV broadcast versions were full framerate 1:1 interlaced cadence for those sections, but it was a long time ago.

[flossy_cake]

Originally Posted by poisondeathray

Rife 4+ models allow for arbitrary framerates, but <4 can only produce powers of 2 (so you have to call them multiple times and selectevery, or use other interpolation at 2nd step) . The best model overall is 2.3 or 2.4 on most content, but models 4+ are faster and are easier to use because of the fpsnum / fpsden . Interpolation is not perfect, there can be artifacts, and you have to manually identify the sections with trim()

Just reading through the docs now... which model did you use for the 23.976 one and did you have to manually identify the scene change with trim()?

[flossy_cake]

Originally Posted by hello_hello

The Bluray version looks better.

It's a bit contentious actually! On other forums some are saying the "remastered DVD" is still better as it doesn't have DNR and sharpening of the BD version (plus the aspect isn't squished, but they didn't notice that).

Personally I am satisfied with the BD version but only because we can unsquish the aspect. If all I had was a BD player without fine-tuning of the aspect then I probably wouldn't find it acceptable.

Is your DVD the original or remastered?

[poisondeathray]

Originally Posted by flossy_cake

That's awesome, I can't even see any blended frames. The question is, can it be done in realtime, i.e opening .avs file directly in MPC-HC? If not, then I'd have to transcode which means generation loss. But maybe it's worth it.

Unlikely in realtime, especially not with the vulkan avs version. The cuda version in vapoursynth is significantly faster if you have a Nvidia card

You can try FrameRateConverter with mvtools2 as well - that might be able to do realtime with multithreading enabled on a decent system. Many settings and has built in artifact masking, and blend fallback when artifacts are severe. Pure flow output can be called with output="flow"

Originally Posted by flossy_cake

Just reading through the docs now... which model did you use for the 23.976 one and did you have to manually identify the scene change with trim()?

Yes, you have to manually identify sections and use Trim() for differential filtering. I don't know of a way to automate that

For the 23.976 version, the 1st part used TDecimate , 2nd part used model=9

o=LWLibavVideoSource("1-1-1-2 to 1-1.mkv")

a=o.trim(0,274).tdecimate()

o.trim(275,0)
z_ConvertFormat(pixel_type="RGBPS", resample_filter="bicubic", colorspace_op="709:709:709:l=>rgb:709:709:f")
rife(model=9, fps_num=24000, fps_den=1001)
z_ConvertFormat(pixel_type="YV12", resample_filter="bicubic", colorspace_op="rgb:709:709:f=>709:709:709:l")
b=last

a+b

I used model=9 so rife-v4, because it was easier with fpsnum/fpsden. Otherwise you have to apply rife twice, then downsample every 5th. e.g. 29.97 x4 => 119.88 , then selectevery(5) for every 5th frame, so they are evenly spaced in time. There are newer models in one of the vapoursynth versions, but they haven't been transferred over yet. Each model is slightly different and may produce better/worse results in some frames

You can try FrameRateConverter with mvtools2 as well - that should be able to do realtime with multithreading enabled on a decent system. Many settings and has built in artifact masking. Pure flow output can be called with output="flow"

[flossy_cake]

Thanks, I think I would prefer a decimate-based solution then.

I did manage to get Rife working and yeah it's definitely not real time -- I'm getting around 2-3 fps at 100% GPU load on old R9 380.

rife.avs:
DirectShowSource("1-1-1-2 to 1-1.mkv")
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:limited=>rgb:709:709:full")
RIFE(model=9,fps_num=24000,fps_den=1001)

ffmpeg -i rife.avs -c:v libx264 -preset medium -b:v 4000000 -pix_fmt yuv420p10le -profile:v high10 -r 59.940 -c:a copy result.mkv

Result: https://drive.google.com/file/d/16Og...ew?usp=sharing

Was expecting a 23.976 output but got 59.94 @ 1:1:1:1:1:1:1:3 & 1:1

[poisondeathray]

Originally Posted by flossy_cake

T

rife.avs:
DirectShowSource("1-1-1-2 to 1-1.mkv")
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:limited=>rgb:709:709:full")
RIFE(model=9,fps_num=24000,fps_den=1001)

ffmpeg -i rife.avs -c:v libx264 -preset medium -b:v 4000000 -pix_fmt yuv420p10le -profile:v high10 -r 59.940 -c:a copy result.mkv

Result: https://drive.google.com/file/d/16Og...ew?usp=sharing

Was expecting a 23.976 output but got 59.94 @ 1:1:1:1:1:1:1:3 & 1:1

-r 59.940 as output option in ffmpeg will add duplicates 23.976=>59.94

If you do not decimate the 1st part in the script, it will not be as smooth because rife will be interpolating from those weird duplicates

Be careful with directshowsource as a source filter - it's not necessarily frame accurate and might give you weird results, especially with temporal filtering or any filter chain that requests multiple frames

-c:a copy from an avs script will output uncompressed audio. Avisynth frameserves uncompressed audio and video. You'd probably want to use the original audio stream and -map arguments for each stream when using -c:a copy . Assuming the original stream map for original.mkv is stream 1 for the audio, stream 0 for the video, it would look something like this:

ffmpeg -i video.avs -i original.mkv -map 0:0 -map 1:1 .... -c:a copy....

[flossy_cake]

Thanks. I tried with -r 23.976 and still get a bad result for the stairs section: https://drive.google.com/file/d/1Efx...ew?usp=sharing

My previous attempt with -r 59.94 resulted in 1:1 60fps on stairs not duplicate.

Anyway it's a moot point as I can't use this filter due to practical constraints.

[poisondeathray]

Originally Posted by flossy_cake

Thanks. I tried with -r 23.976 and still get a bad result for the stairs section: https://drive.google.com/file/d/1Efx...ew?usp=sharing

result2.mkv iss different, with slightly different artifacts, but still 23.976 unique frames /s on the stair section . It might be source filter differences, and I'm unsure if GPU makes a difference (it shouldn't with vulkan)

[hello_hello]

Originally Posted by flossy_cake

I recognise that number -- it's also the diff between 704 and 720 width: 704 * 1.0227 = 720. Could be a coincidence though, I don't really know.

No co-incidence. Using a generic PAR (there's a list of PAR's here).

720 x (16/15) / 576 = 4:3

For an mpeg4 PAR

704 x (12/11) / 576 = 4:3
or
720 x (12/11) / 576 = 15:11

The mpeg4 PARs are the mpeg4 equivalent of the original ITU PARs derived from the standard for digitising analogue video. They're almost the same as ITU but easier to remember and work with because they only result in two DARs for both NTSC and PAL DVDs, 20:11 and 15:11 (the mpeg4 equivalent of 16:9 and 4:3).

[hello_hello]

Originally Posted by flossy_cake

It's a bit contentious actually! On other forums some are saying the "remastered DVD" is still better as it doesn't have DNR and sharpening of the BD version (plus the aspect isn't squished, but they didn't notice that).

Personally I am satisfied with the BD version but only because we can unsquish the aspect. If all I had was a BD player without fine-tuning of the aspect then I probably wouldn't find it acceptable.

Is your DVD the original or remastered?

I haven't dug them out yet but I'm pretty sure they're not the remastered version. They're pretty old.
I prefer the Bluray because it's obviously been remastered for modern displays. The gamma and contrast looks better. Apparently back in the dark ages the BBC were obsessed with the picture being bright. Some of the actors on my classic Doctor Who DVDs complained about that in the commentary.

The other DAR issue is the HDMI spec which says PAL and NTSC should be exactly 16:9 or 4:3, so modern players/displays resize that way. Apparently DVD players with analogue outputs tend to use ITU resizing for analogue and generic resizing for HDMI, so the DAR could be mpeg4 for the remastered DVD version and it's generally being viewed a bit squished too, so it looks the same as the Bluray.

I'm not a fan of video that looks sharpened, but just based on the small sample I've seen I don't think the sharpening was too over the top. I haven't seen the remastered DVDs though, so I can't comment on those.

PS I don't actually know, but I suspect the bluray was created using some sort of interpolation method rather than it being de-interlaced and re-interlaced. I have some NTSC DVDs of classic Doctor Who that were created that way. They look like standard interlaced NTSC but they don't de-interlace well. Lots of aliasing and only QTGM seemed to do a decent job. If the Bluray version was created the same way you might find it's a job for QTGMC once you get to scenes with objects with sharp edges etc, even though BWDIF seemed to do a decent job with the sample. For HD you could probably get away with speeding QTGMC up a fair bit, ie QTGMC(Preset="Medium") and it'll still do a better job than most de-interlacers.

[flossy_cake]

Originally Posted by flossy_cake

the problem is that TDecimate can't seem to detect the cop walking up the stairs is 1:1 and fails to identify it as "video"

Solved this with viddetect=2. The motion blur is a bit ugly but still better than the harsh stuttering without it. This opens the possibility of creating a VFR file with native rates for both cadences, if I can figure out how to do it...

[flossy_cake]

Found this post by hello_hello explaining it somewhat (thanks): https://forum.doom9.org/showthread.p...53#post1783153

It sounds like applying the mkv timecode file requires re-encoding (generation loss) though -- is this correct?

But other stuff I read seemed to imply the file can be remuxed into a new mkv file without having to re-encode? edit: actually no that can't be right now that I think about it since TDecimate is removing frames so as soon as you change any frame it all needs to be re-encoded. The problem is this degrades image quality (generation loss) and takes a very long time. Is it possible for avisynth to do the VFRing in real time? I'd imagine at least 1 pre-pass would be required to generate the timecode file, but then after that can avisynth take the timecode file + the original file and produce a VFR output from it in realtime?

[hello_hello]

Originally Posted by flossy_cake

I'd imagine at least 1 pre-pass would be required to generate the timecode file, but then after that can avisynth take the timecode file + the original file and produce a VFR output from it in realtime?

Not in realtime as Avisynth only supports a constant frame rate (I'm not sure about VapourSynth). Typically the CFR is the average frame rate and the timecodes are used when muxing to make it VFR, or for x264 you can add the timecodes file to the command line and encode in VFR mode (I don't use x265 so I don't know if it has a VFR mode).

[flossy_cake]

Ok cool.

I think I'll just use TDecimate to 24p in real time and live with the motion blur on the 30p->24p converted sections as they aren't very common in this show. Plus an added benefit is that the native 24p sections can be output natively at multiple of 24hz instead of baking in the 3:2 judder @ 60p. I have mixed feelings about 3:2... I suppose it's kind of interesting and charming in a way, but also a bit jarring on panning shots. My main display isn't sample-and-hold so maybe that's exacerbating it. When there's not much camera movement though it does seem to imbue a kind of dream-like feel though which I find amusing. I sort of want to watch it and pretend I'm living in a 60hz country haha

For Fawlty Towers I saw that LAV Video Decoder has recently added bwdif so I might just deinterlace in realtime and save some storage space. DXVA deint is not bad also (tag file with [deint=video] in madvr) but it has this weird delay on the 1px patterns in the 576i25 clip in the OP.

Thanks again for all the help and code examples, which sped up my learning a lot. Because of this thread I also discovered the AssumeFPS() function to slow PAL stuff to 24p in realtime. This is really quite amazing to me but I'm still getting used to actors' voices being low and slow after hearing them chipmunked for the last 2 decades.

[hello_hello]

Given you use MPC-HC, have you tried ReClock? I'm still using it on XP but I assume it works for newer Windows. It'll slow PAL down to 24fps and/or pitch correct the audio without changing the video speed. I think it's 32 bit only though.

[flossy_cake]

Originally Posted by hello_hello

Given you use MPC-HC, have you tried ReClock? I'm still using it on XP but I assume it works for newer Windows. It'll slow PAL down to 24fps and/or pitch correct the audio without changing the video speed. I think it's 32 bit only though.

Yeah that's why I'm not using it as I'd need to run a separate 32-bit MPC just for those videos which clashes a bit with the way I've got things set up.

Although there's a lot of AVS dll's which are 32-bit and those won't work with 64-bit MPC-HC either so maybe I need to figure something out.

The AssumeFPS(24,1,true) seems to do the trick though -- it slows down both the video and audio to 24. It's not just the pitch that's wrong, it's the whole speed of dialogue, the intonation of actors speaking feels slower or something. For sitcoms it seems to make things seem... less comedic? Also have a look at this.