Does Frame Rate Matter?

[Danette]

I've been doing some deeper diving into improving play of hybrid TV episodes and found that using TDecimate(Cycle=10,CycleR=1) does the trick for some of these episodes. Of course, this decimates only 10% of an NTSC video, leaving an fps of 26.973. It gives uniformly smooth playback and no sync issues.

Is there any issue leaving these videos at 26.973 frame rates?

Incidentally, I've tried TDecimate(hybrid=1), TDecimate(hybrid=3) and TDecimate(Mode=2,Cycle=10,CycleR=1), but all of these generate inferior results.

[manono]

Is there any issue leaving these videos at 26.973 frame rates?

For playback on a computer? No issues that I can think of.

These are from DVDs? Out of curiosity, do you have a sample we can see?

[Asmodian]

That is a super weird framerate so there is lots of potential for incompatibility with non-PC devices.

Also, those of us who care about judder have solutions for normal frame rates that might not work for that, but I assume this is a non-issue given the way this source was created (this level of judder is likely baked in already). madVR's smooth motion would work.

[Danette]

For playback on a computer? No issues that I can think of.

These are from DVDs? Out of curiosity, do you have a sample we can see?

Seems to work on a TV. Yes, these are from DVD's. This particular series has numerous challenges that have proven very interesting.

Sample: https://www.mediafire.com/file/aw4tsjp9eouhm9p/Source_Track01.m2v/file

This sample seems to have a 5-5 pattern.

[johnmeyer]

I've been doing some deeper diving into improving play of hybrid TV episodes and found that using TDecimate(Cycle=10,CycleR=1) does the trick for some of these episodes. Of course, this decimates only 10% of an NTSC video, leaving an fps of 26.973. It gives uniformly smooth playback and no sync issues.

Is there any issue leaving these videos at 26.973 frame rates?Why are you doing this??

Hybrid TV means that a portion of the show is filmed (24 fps) and then telecine is added to have it show at 30 fps. Other parts of the show (often the credits) are at 30 fps interlaced.

Applying:

TDecimate(Cycle=10,CycleR=1)

is going to butcher both the film content as well as the true video. You will end up with some really weird cadences, I would think. Watch carefully on any scenes where the camera pans horizontally. That should show any problems.

[Sharc]

Seems to work on a TV. Yes, these are from DVD's. This particular series has numerous challenges that have proven very interesting.

Sample: https://www.mediafire.com/file/aw4tsjp9eouhm9p/Source_Track01.m2v/file

This sample seems to have a 5-5 pattern.
The sample seems to have a fields pattern like
2-2-2-2-3-2-2-2-3
which could have its root in a 25i to 30i conversion.

Did you try
TFM().TDecimate(Cycle=10,CycleR=1) #gives 26.973fps
AssumeFPS(25)

You would have to resample the audio accordingly.

[hello_hello]

I remember a long time ago coming across some episodes of this show.... I can't remember where or why, but I recall at the time thinking someone had made a mess of them, mostly because they seemed to be playing fast. It's impossible to tell from the sample, and it's a fair hike down from 26.973 to 24fps, but I'm wondering if the speed up is deliberate. I thought maybe it was done to fit into a particular duration, and you'd hope that sort of thing wouldn't find it's way to a DVD, but now I'm thinking along the same lines as Sharc....

TFM()
TDecimate(cycle=20,CycleR=2)
AssumeFPS(24)

You'd have to find a section with normal speech and slow the audio to match to see if it's natural. It's not obvious from the sample whether 26.973fps is too fast, but slowing it down to 24fps doesn't look too slow.

TDecimate's hybrid modes expect combinations of telecined film (23.976 after IVTC) and interlaced video (29.97fps after de-interlacing). I doubt the hybrid modes would work well with anything else.

PS. If you add the audio to a script, you can slow it down with this function.
AudioSpeed (https://files.videohelp.com/u/210984/AudioSpeed%202020-08-26.zip)
It'd be something like:

Video = mpeg2source("D:\Source_Track01.d2v")
Audio = FFAudioSource("D:\Audio.ac3")
AudioDub(Video, Audio)
TFM()
TDecimate(cycle=20,CycleR=2)
AssumeFPS(24)
AudioSpeed(24.0, 27000.0/1001.0, PitchCorrect=true) # Add Info=false to disable the overlaid text.
ConvertAudioTo16bit() # as required

Then open the script with a player such as MPC-HC to see how it looks and sounds.

[Frank62]

We had these odd framerates after correct decimating with Michael Landon's Highway To Heaven some years ago. There were some episodes intentionally accelerated - some say, to have more room for commercials. Maybe this could be the point here. If so you should correct the framerate to 23.976 in the end with an assumefps().

[johnmeyer]

We had these odd framerates after correct decimating with Michael Landon's Highway To Heaven some years ago. There were some episodes intentionally accelerated - some say, to have more room for commercials. Maybe this could be the point here. If so you should correct the framerate to 23.976 in the end with an assumefps().If the episode was accelerated, isn't that usually done by deleting frames and, if so, wouldn't deleting even more frames be a bad thing?

If a movie that has been telecined was sped up, I'd suspect that this would be done by removing some of the pulldown fields. If so, the correct thing would be to create a TDeicimate Cycle/CycleR ratio that would eliminate fewer than the normal number of fields (it would be a LOT more than 1 out of 10, as shown in post #1).

You'd also need to determine what needs to be done to the audio.

[Frank62]

If the episode was accelerated, isn't that usually done by deleting frames and, if so, wouldn't deleting even more frames be a bad thing?

That's possibly why the thread starter deleted 1 of 10 instead of the normal 1 of 5 resp. 1 of 6 for back-to-PAL-conversion. So he deleted fewer, because there were already too less. The resulting pseudo-framerate is too high and has to be slowed down - if from PAL not that much, from 26.973 to 25 - to get the original speed.

[hello_hello]

The sample isn't long enough to tell if it's regular, but stepping through the frames after TFM, these are the duplicates.

3,13,23,33,43,54,64,74,84,94,104,114,124,134,144,154,165,175,185...

If that's regular, I assume my original Cycle=20 and CycleR=2 is wrong and it should be

TFM()
TDecimate(Cycle=111, CycleR=11)

and the result would be 26.9738fps, or 1000000/37073 to be precise (according to Avisynth).

[Danette]

Thanks for all of the insight. I hadn't considered the possibility of a sped-up video. Of the 36 episodes in this season, four are like this sample. Re-checking, I found that the bulk of this season are the expected ~25 minutes, correctly telecined, while these four episodes are ~22 minutes, which does support the speed difference. I do recall having encountered this type of thing about 15 years ago with the "Combat!" series. I will have to add taking a quick look at all future series to rule-out this possible difference in time lengths.

When I first encountered such things, the reason has been that, when a studio doesn't have access to the original 35mm film, they often have to use what they can find, and this may be the sped-up episodes that were done this way for syndication. Rather than cutting scenes, the syndication effort might choose to increase the speed to deliver the entire original episode. So, these oddities apparently pop up more often than I thought.

I haven't had time to try some of the above approaches, but will and I will report back on what I find.

[Frank62]

when a studio doesn't have access to the original 35mm film

Your source seems to have PAL origin. European studios access to U.S. 35mm material? We do this since 2007 and there wasn't one single case where we had access to anything else than what the licensor gave us - and that's the masters he made. From new restored great quality down to syndicated, blended, very old 1'' sourced tapes (often)
Apart from that: 35mm access, scanning, restoring nowadays is financially only possible for very well selling feature films, even if you do restoring in-house as we do. A whole series? No way.

[Danette]

Good catch, for those that suspected the speed problem. The script offered by hello_hello worked great on these four episodes. The cycle=10,CycleR=1 still seems indistinguishable, upon viewing, vs. the other decimation suggestions, so I've stayed with that.

I can't preview the script though, at least not in MPC-HC (VDub crashes), as MPC-HC throws off a "Script error: there is no function named 'MPEG2Source'." Googling the issue hasn't helped. If anyone has a solution, it would preclude the need to wait for full processing of the file.

[StainlessS]

VDub crashes
You using VDub2 ? :- https://forum.doom9.org/showthread.php?t=172021

"Script error: there is no function named 'MPEG2Source'."
Do you have "DGDecode.dll" in your plugins folder ? [Comes with DGIndex, un-official x64 DGDecode.dll is also available from somewhere]

[hello_hello]

I can't preview the script though, at least not in MPC-HC (VDub crashes), as MPC-HC throws off a "Script error: there is no function named 'MPEG2Source'." Googling the issue hasn't helped. If anyone has a solution, it would preclude the need to wait for full processing of the file.

How do you normally open DVD video?

I remember you using MeGUI, so if that's correct you can index with MeGUI/DGIndex and edit the script. You'll find DGDecode in the MeGUI Tools folder, but after indexing, MeGUI will open the video like this.

LoadPlugin("C:\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Source_Track01.d2v")

I think there's other source filters (maybe older ones) that also open video with mpeg2source, so MeGUI plays it safe and makes sure DGDecode is being used.

DGDecode_mpeg2source("D:\Source_Track01.d2v")

This should work too though.

LoadPlugin("C:\MeGUI\tools\dgindex\DGDecode.dll")
mpeg2source("D:\Source_Track01.d2v")

Failing that, just open the video with whatever source filter you've been using until now. You can use FFMs2 to open the video and audio together so you won't need AudioDub(), if they're in the same file, but I guess I assumed you were indexing with DGIndex and extracting the audio as a separate file.

FFMS2("D:\Something Something.mkv", atrack=-1)

[StainlessS]

Didn't realize that Danette was using MeGUI, that explains it perfectly.

[Danette]

Regarding MPC-HC failure to play avs files:

I do use VDub2 and "DGDecode.dll" (32-bit) is in the plugins folder (AviSynth+).

I do normally use MPC-HC to view video, but have never tried it with avs files (works fine for all type of video files I’ve used). I do all script development and previewing in AvsPmod and, sometimes, in Vdub2 (which doesn’t crash with avs files when not using the audio dub of the above script).

Tried the script:
LoadPlugin("C:\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Source_Track01.d2v") and Mpeg2source("D:\Source_Track01.d2v")
but it threw off the warning about not using a 64-bit DGDecode.dll version in 64-bit AviSynth. Tried placing the 64-bit DGDecode.dll from MPEG2DecPlus into the plugins folder (AviSynth+), but no help.

I do use MeGUI, but just for processing avs files with OneClick. In preparing the avs files, I demux video, audio and chapters, and then use StainlessS’ DGIndex Batcher. So, FFMs2 would complicate things. Previewing is done in the AvsPmod player and Vdub2, as necessary (AvsPmod has no audio player).

[StainlessS]

Assuming that you are using 32 bit, take out the x64 version of DGDecode.dll from plugins, it dont belong there.
If you get some warning about 64 bit, then sounds like you are using eg 64 bit version of MPC-HC (or whatever issues that warning).
Can ONLY use x64 apps with x64 Avisynth and x64 plugins, cannot swap and change [same for any other non Avs app, dlls].
x86 is probably the least problematic version of AVS, so maybe also get x86 version of MPC-HC. [can be installed side by side, but need to open with the correct one].

[videoh]

un-official x64 DGDecode.dll is also available from somewhere Official DG version has been available for a while.

[StainlessS]

Thanks Don, Probably the version that I'm using then, thought was still unavailable.

EDIT: Nope, one I'm using is by JoshyD, from 2010, UpConv=1, bugged. [probably why I sometimes use 32 bit for VOB,
and re-rewrite as UtVideo AVI if I want to use x64 for something].
Have not tried MPeg2Dec3 mod (or whatever its called).
The x64 MPeg2Source on Wiki is still JoshyD ver$ from 2010.

[Danette]

Assuming that you are using 32 bit, take out the x64 version of DGDecode.dll from plugins, it dont belong there.
If you get some warning about 64 bit, then sounds like you are using eg 64 bit version of MPC-HC (or whatever issues that warning).
Can ONLY use x64 apps with x64 Avisynth and x64 plugins, cannot swap and change [same for any other non Avs app, dlls].
x86 is probably the least problematic version of AVS, so maybe also get x86 version of MPC-HC. [can be installed side by side, but need to open with the correct one].

Yup: I was using the 64-bit version of MPC-HC (didn't realize that there was a 32-bit version). Works fine, now. Thanks.

I should add that, while MPC-HC 32-bit will play simpler scripts, it does choke on the audio dubbing that the above script generates. So, it can't be used for preview purposes.

[videoh]

Thanks Don, Probably the version that I'm using then, thought was still unavailable. Official version:

http://rationalqm.us/dgmpgdec/dgmpgdec.html

Features a 64-bit dual-synth DGDecode and a speed-optimized DGIndex.

[StainlessS]

That will do nicely, thanks very much. :thanks:

[StainlessS]

it does choke on the audio dubbing that the above script generates
If you're talkin' bout Hello_Hello script, then probably using Timestretch() and SSRC() which likely are producing stuttering
play, both are fairly heavy on processing, only option to save as Lossless AVI and play that.
[Might possibly play better in VD2 (EDIT: 32 bit)]

[hello_hello]

That's the only thing I find annoying with MPC-HC. As far as I know there's no way to tell it to wait for frames when there's slow filtering in a script, and when there is, it doesn't take long for MPC-HC to give up.

I'd used MPC-HC for previewing scripts for something like eight years before it occurred to me I could often keep MPC-HC happy by temporarily adding AssumeFPS(SomethingSlow) to end end of a script (that's how smart I am).
Of course that's no help for checking the audio sync in this case.

For pitch correction, Audio Speed uses the TimeStretch plug-in, and for Aisynth+ it uses it's version. Without pitch correction it tries to resample with SSRC first, and if that fails it uses Avisynth's internal filters.

For stereo audio, which I assume is the case here (TV show from the 60's), I thought TimeStretch was at least real-time fast, but I could be remembering wrong.

Danette, PitchCorrect=false for AudioSpeed should help, and hopefully allow you check the audio/video sync straight from the script. When you're happy, enable it again (if the audio needs pitch correction). Setting Info=false while checking the audio from the script probably wouldn't hurt. I'm not sure whether overlaying text on the video (via Avisynth's Subtitle function) is very CPU intensive. The text is static when Info=true, so probably not....

[StainlessS]

TimeStretch was at least real-time fast
OK, maybe its me thats wrong, I thought it was a bit slow.
Note, IanB said something like, "Difference in quality between ResampleAudio() and SSRC() is minimal and has been for some years",
or words to that effect. It was re-written quite a while ago [there are posts, articles that say SSRC is way better but that ain't true anymore],
also SSRC is more likely to fail with certain source/destination samplerate conversions, where ResampleAudio will succeed.
[think re-write was in v2.58 or prior]

Static Subs not too CPU intensive, also think Pinterf sped up subs quite a bit, they used to be really quite slow,
subs changing per frame used to cripple speed, not so much now.

[hello_hello]

StainlessS,

I converted both stereo and 5.1ch audio as a test, and ran them though AudioSpeed using the settings I suggested earlier, opening the script with foobar2000 and converting to AC3, because fb2k displays the speed relative to real time in the progress window and AC3 is a pretty fast codec. If the output was wave I think my hard drive speed could be a bottleneck. I'm using a 10yo PC.

AudioSpeed(24.0, 27000.0/1001.0, PitchCorrect=true)

2ch audio to AC3 without AudioSpeed in the script ran at roughly 180x real time. With AudioSpeed it was roughly 150x, although it took a few seconds to ramp up to that speed. 5.1ch audio is a whole other kettle of worms. 165x without AudioSpeed, and roughly 28x with it, although still a fair bit faster than real time.

I just realised the 2ch audio I used was 44.1k rather than 48k... sigh... although I doubt that'd change the relative speeds much.

For SSRC, AudioSpeed first attempts to resample using a Try/Catch thingy, suppressing any "SSRC can't do that" error messages and if necessary, moving on to Avisynth's filters instead. I do recall reading that SSRC isn't much better these days, but SSRC also has a fast and slow speed argument, and whether slow produces much better quality than the default of fast, I have no idea, but that lack of idea led me to include SSRC in the function, just in case.

Info=true shows when SSRC isn't used... if PitchCorrect=true or if SSRC fails. Playing around a little now, I had a hard time finding a "reasonable" numerator and denominator that'll cause it to fail. Here's an unreasonable one:

AudioSpeed(122.3674, 24.888)
The Resampling line for Info=true should change to "ResampleAudio", rather than "SSRC", assuming PitchCorrection hasn't been enabled.

[StainlessS]

Thanks for that HH.
Not sure but think that ResampleAudio was re-written to use similar to SSRC, "ShiBashi" algo, Just looked it up, actually "Shibata" Sample Rate Converter.
MPC-HC sometimes is a bit jittery, VDub2 often better when so.

EDIT: Yesterday, apparently UK did 1/3 Million jabs, getting better at it.
https://metro.co.uk/2021/01/17/uk-nearly-on-home-straight-as-324000-vaccinated-in-one-day-13916857/
Maybe mine in bout 2 or 3 weeks. :)

EDIT: Horrific new research, "One in eight ‘recovered’ Covid patients ‘die within 140 days’.
https://metro.co.uk/2021/01/18/one-in-eight-recovered-covid-patients-die-within-140-days-13920415/?ito=cbshare
A third of people who recovered after suffering from severe Covid were readmitted to hospital within five months with complications including heart problems, diabetes and chronic liver and kidney conditions. New research has shown the devastating long term impact of the virus with one in eight people dying within five months of diagnosis. The University of Leicester and the Office for National Statistics found that out of 47,780 people discharged from hospital in the first wave, 29.4% were back in hospital within 140 days and 12.3% died. Covid survivors were three and half times more likely to be readmitted to hospital and die compared to other conditions. The study – which has not yet been peer reviewed – is believed to be the largest yet that looks at what happened to people discharged from hospital after Covid.

[hello_hello]

Using MPC-HC for previewing scripts is such a habit I forgot about SMPlayer again. It will patiently wait for frames.
Some MPC-HC vs SMPlayer things it's handy to know....

For SMPlayer, under Options/Performance, "Allow frame drop" must be unchecked. If the video won't play n real time, any audio will be out of sync.

MPC-HC doesn't lock scripts while they're playing if it's internal Avisynth source filter is unchecked (at least on XP), but you can edit and re-save scripts while they're playing using a text editor that ignores the locked status. To see the changes you can open the edited script in a second instance of MPC-HC, or to refresh the video in the current player, CTRL+E re-opens the currently playing file.

I haven't found a way to prevent SMPlayer from locking scripts, and there's no shortcut to re-open the currently playing file that I could see, however unlike MPC-HC, the Stop button doesn't reset the playback position to the beginning when the "remember position" option is enabled under Options/Playback, so for SMPlayer, to re-open a script and preview the changes you can click Stop and then Play.

SMPlayer doesn't have an option to navigate to a particular frame number as MPC-HC does, only to a specified point in time.

On the plus side, when you re-open a script in either MPC-HC or SMPlayer, they re-open it at the same position in time, rather than the same frame number. It means when you're experimenting with any type of filter that changes the frame count, such as bob de-interlacing or IVTC, after refreshing the preview it'll be re-opened at the frame showing before the refresh, even if it's frame number has changed. MeGUI's preview, and from memory VirtualDub and AvsPMod, all re-open the video at the previous frame number, which seems borderline mental to me, because when previewing a script where the frame count has changed, a refresh will take to you a completely different place in the video. That drives me nuts.

[Danette]

I’m revisiting this issue, again, with the original question in mind: “does frame rate matter.” The reason is that I’ve found that the affected videos have such irregular duplicate frame patterns that even the best solution (TDecimate(cycle=10,CycleR=1)), of the many above, still leaves some duplicates that are annoying - just enough to be worth trying to do better. It becomes a matter of; do I want the duplicates in the front end of the video, or the back end.

Doing “better” means time-stretching the video, as well, because these videos that were found by the DVD studio (all they could find) had been previously sped-up by the Lexicon process to maintain the original content, but allowing more commercials. It also means trying to eliminate the remaining duplicates. So, when I maximized duplicate removal with the above script, my fps went to an odd rate. Of course, audio sync becomes an issue, but hello_hello’s suggestion:

Video = mpeg2source("D:\Source_Track01.d2v")
Audio = FFAudioSource("D:\Audio.ac3")
AudioDub(Video, Audio)
TFM()
TDecimate(cycle=20,CycleR=2)
AssumeFPS(24)
AudioSpeed(24.0, 27000.0/1001.0, PitchCorrect=true) # Add Info=false to disable the overlaid text.
ConvertAudioTo16bit()

kept both the audio in sync and stretched the time to normal length while achieving a more normal 24 fps. However, the time correction seems to have been more coincidental than something repeatable with other videos and I have other TV series that contain these sped-up tricks.

So, I decided to drop the IVTC approach and just use QTGMC(InputType=0) on these 4 episodes because, as always, it gives seemingly perfectly smooth play and it worked here, as expected (QTGMC is amazing). I had to forego the use of a TFM trick to eliminate moire effect (described in another thread), but it’s just for these 4 videos and the staccato effect of duplicates is more annoying than the moire effect.

I also employed AssumeFPS(54), after QTGMC, to time stretch the video appropriately (h_h’s audio trick is also being utilized). Of course, this leaves me with a 54 fps video, but it does play well on several TV’s, other players and computers.

So, again, does anyone see any nagging problems with the odd frame rate? Also, if anyone sees a way to get a more normal fps rate, while selectively achieving a desired time length (each speed-up requires a different time length target), it would be welcome.

[johnmeyer]

I would recommend sticking with TFM/TDecimate.

When patterns wander a bit, you can often get much better results by increasing the Cycle window. This will slow things down a little, but you should get much better results.

The "1 in 10" is not quite accurate enough. I looked through 100+ frames, one field at a time and found that in 108 frames (216 fields) there were exactly 10 fields that were duplicated.

TFM()
TDecimate(CycleR=5, Cycle=108)

[hello_hello]

Yeah, I'd try the pattern I suggested earlier.
TDecimate(Cycle=111, CycleR=11)

TDecimate also has Mode=7. You specify the desired frame rate and TDecimate will remove duplicates to get you there. Trouble is, if it's not the correct frame rate it'll still leave duplicates behind or sometimes remove non-duplicates. I'd try 27000.0/1001.0 to begin with, as that's what 1-in-10 decimation gives you.

You could also try dedup. Normally it outputs a timecodes file for VFR encoding, but you might be able to slow the video to 24fps after they're removed instead, and slow the audio to match.

The only thing that might prevent audio time correction from working is if the duplicate frame pattern is very irregular and you don't use M-in-N decimation, or maybe M-in-N decimation with a huge frame cycle. For M-in-N decimation such as 2 in 20, you're always left with 18 frames spread out over the same time period as the original group of 20, and each cycle of frames could be looked at as a reset for the audio sync. As long as you use the frame rate after decimation as the denominator for AudioSpeed (do you check with Info()?), and the AssumeFPS frame rate for the numerator, the A/V sync should be fine.

If after decimation, you check the A/V sync with the original audio and they're in sync (before AssimeFPS), time stretching both by the same amount won't change that. If they're already out of sync it can only be because the duplicate frames were in a such un-even pattern, removing them caused the video to lose sync with the audio, and time stretching both can't fix that.

[Frank62]

Not only pulldown-patterns change in these syndicated episodes, but also the rate of "missing" double fields. You have to try several cycles. We usually had about 3 to 4 changes per episode.

To leave it as is with just QTGMC is not a good idea.

[Danette]

Yes, I did try TDecimate(Cycle=111, CycleR=11) and TDecimate(Cycle=108, CycleR=5) and both exhibit the same problem in the last half of the video. TDecimate(Mode=7) did greatly improve the duplicate elimination over specifying the cycles, but play was not as good as QTGMC. With the short sample I provided, you can’t see the change in the pattern throughout the video (I didn’t realize there was such an issue when I provided the sample). I think that Frank62 touched on this from his own experiences.

As you know, by examining the sample, it is hard to see a telecine pattern - there are varying combed frame lengths and duplicate frames in the source. DGIndex also identifies the video type of these sped-up episodes as video, not film. It seems that the Lexicon speed-up process mangles the structure pretty badly (though I am glad that this speed-up process was used rather than cutting content out). QTGMC(InputType=1) provides smooth play throughout. Given this, I’m having a hard time understanding why it would be better to continue trying to work the IVTC angle rather than just letting QTGMC deal with it.

Of course, using either Mode=7 or QTGMC or some ideal decimate cycle, puts the fps at 23.976 or 59.94, and this retains the source sped-up length at 22 minutes. To deliver the corrected speed of 25+ minutes, I added AssumeFPS(21.5) after TDecimate(Mode=7) or AssumeFPS(54) after QTGMC(InputType=1). So, I’m left with these odd frame rates, which do play correctly, and are in sync (thanks to AudioSpeed), on all the above mentioned devices.

Basically, I’m wondering why it is that I should not be happy with the QTGMC and 54 fps approach. I will gladly abandon this approach if there is a compelling reason to do so and am very interested to hear opinions on this.

[hello_hello]

If you bob-deinterlace a progressive source, the field from each frame becomes a full frame, so from a motion perspective, nothing changes.
A B C D
becomes
AA BB CC DD
at twice the frame rate.

It won't help if full frames are repeated.
A B C C D
becomes
AA BB CC CC DD
at twice the frame rate.

For a telecined source it's better than field matching without decimation. For standard 2:3 telecine, field matching gives you something like this. One of the "B" frame fields is repeated, and one of the "D" frame fields is repeated, but for each group of five frames, field matching throws one repeated field away, and the other repeated field is matched twice to invent a duplicate frame.
A B C D D
whereas after bobbing you'd have
AA BBB CC DDD
at twice the frame rate.

In a perfect world you'd field match and remove the duplicate frames as it gives you the original progressive frames untouched, and of course for standard telecine that takes you back to 23.976fps. Bobbing re-imagines every field into a new full frame, so there's no original frames left, but sometimes, especially for hybrid sources, bobbing is a simpler way to do it, and looks smoother than field matching without decimation.
For your source bobbing must still be creating a group of three repeated frames instead of two now and then, but not as often as for standard telecine, where there's more repeated fields.

[Sharc]

.....Basically, I’m wondering why it is that I should not be happy with the QTGMC and 54 fps approach. I will gladly abandon this approach if there is a compelling reason to do so and am very interested to hear opinions on this.
Did you already try FDecimate(...) or FDecimate2(...) in place of TDecimate(Mode=7)? It may help with irregular patterns.

[Danette]

So, in these sped-up episodes, it appears that bobbing is the better solution than field matching, in terms of smooth playback and, yes; by using QTGMC I do have groups of three repeated frames instead of two now and then. Thanks for making those two approaches clear.

I did try FDecimate() and it performs about the same as TDecimate(Mode=7).

So, I'm good to go, I assume, with the odd frame rates ...unless I run into a device that can't handle it.

[Frank62]

Well, your decision... But you are still left with:

-jerkiness (does that word exist?) - Bobbed it certainly seems smoother, because there are double as many frames than before, so the stuttering ones are more spread, but they are all still there...

-faster speed than originally meant, sometimes a bit faster, sometimes a bit slower, but overall wrong speed

-sound that had been adapted to the speed changing original, and sure not with algorithms that keep pitch(!)

We used for Decimating - by the way - TDecimate with mode 2 and calculated the changing pseudo-framerates. You have to find the correct factors that leave you as less as possible dups, which then also can be used for the sound.

[Danette]

“Jerkiness”, “judder”, “stutter” - whatever - yes; it is still there with QTGMC, as measured by numbers of duplicates, but in normal playback, it can’t be observed, unlike the decimation attempts. I agree that it would be much better to have ‘clean’ progressive streams, but all decimation processes that I’ve tried on these sped-up episodes are leaving too much stutter.

As I looked, frame-by-frame, I could see that virtually all duplicates were removed with many of the decimation approaches, but needed frames seemed to also be missing, which leave gaps in the stream and creates the stuttering playback. It’s as though most frames are moving at one-inch intervals but, at random points, a frame-to-frame move is in two-inch intervals, which creates the stuttering playback. However, I don’t think that non-duplicate frames are being removed, but I can’t explain why the scene jumps forward between the two frames.

The vast majority of TV series I encounter respond nicely to IVTC, but there are some hybrid videos (I prefer to call them mangled) that respond better to QTGMC. These sped-up videos are among the QTGMC group.

Note that I actually slowed the speed down, so speed issues with QTGMC are moot. Additionally, the AudioSpeed function does seem to provide the correct pitch. At least, to my ear.

[Frank62]

I agree that it would be much better to have ‘clean’ progressive streams, but all decimation processes that I’ve tried on these sped-up episodes are leaving too much stutter.
Try with mode=2. And you have to find out the correct factor/pseudo framerate. We had two sources, one progressive with German sound, but very bad picture. So we were able to find the correct factor for decimating by aligning. When found, then decimating worked pretty well with rather no stuttering left. Without second source it may be rather hard to find the factor, I fear.

The vast majority of TV series I encounter respond nicely to IVTC, but there are some hybrid videos (I prefer to call them mangled) that respond better to QTGMC.
If you use QTGMC for hybrid video you get the best result for the interlaced native 29.97fps parts. The pulldowned portions will still stutter. The only way to manage hybrid sources - if you want a progressive final result - is to handle 29.97 and pulldowned 23.976 scenes separately. We adapted the 29.97 sections by deinterlacing with QTGMC and afterwards converting with motion flow (we used Alchemist, but the converter some made here is also very good, sometimes better than Alchemist, even better than some A.I. approaches I tested).

Note that I actually slowed the speed down, so speed issues with QTGMC are moot. Additionally, the AudioSpeed function does seem to provide the correct pitch. At least, to my ear.
You kept pitch. What I tried to say was, that the algorithms they used for the SOURCE surely did NOT keep pitch. So the scenes that are more accellerated will be higher than the scenes less accellerated. Without handling each seperately by using different factors the sound will never be 100% ok. Maybe the differences are not high, then you are lucky. If not ther may be quarter tones higher or lower at transitions, especially when there is music... :)

[Danette]

Tried TDecimate(mode=2) and result is the same as mode=7.

The video has two sections: one section is clearly 1 dup in 5 and the other section is clearly 1 dup in 10. If I use Decimate(cycle=10,cycler=1), then about 90% of the video plays smoothly. If I use Decimate(cycle=5,cycler=1), then about 10% of the video plays smoothly. These two patterns repeat in varying segments throughout the video.

I probably could find each transition point and apply the appropriate decimation, but the time commitment would be significant.

As a hobbyist, I don't have the investment in various professional tools, such as you do for your studio work, so I'm pretty much limited to Avisynth.

[Frank62]

TDecimate(mode=2) requires no cycle, but a framerate. This could f. e. be something like 24.385. But you are of course right: If the pattern" changes that often, it's a waste of time.

As I said: Avisynth and the fabulous people here provide a motion-flow-framerateconverter that is sometimes even better than professional tools.

[Danette]

Yes, I'm afraid it is a waste of time chasing those two patterns around. fortunately, QTGMC, while not ideal, gives the smooth playback.

When you say: "motion-flow-framerateconverter", are you referring to some specific functions that haven't been raised here, or is this a generalization for some of the tools that have already been explored in this thread? I agree about the knowledge and creativity by so many members on this forum. I bring my problems here and generally get solutions that I never envisioned or expected.

[Sharc]

It's about synthesizing of new frames from existing frames by motion interpolation in order to match a desired new constant frame rate.
There exist Avisynth filters for this purpose.
See for example here:
https://forum.doom9.org/showthread.php?t=174793
https://www.svp-team.com/wiki/Manual:SVPflow

[Frank62]

To make it clear: This was just my answer to your statement:
"As a hobbyist, I don't have the investment in various professional tools, such as you do for your studio work, so I'm pretty much limited to Avisynth."

You will not need motion-flow-converting here at all. This was just meant for hybrid sources that were mentioned before, and there only for the portions in native 29.97fps.

[Danette]

You will not need motion-flow-converting here at all. This was just meant for hybrid sources that were mentioned before, and there only for the portions in native 29.97fps.

Thanks for mentioning the motion-flow-converting aspect. I decided to try both FrameRateConverter and InterFrame, and both provide much better play, smoothness wise, than using either Decimate(cycle=10,cycler=1) or Decimate(cycle=5,cycler=1) alone.

Using cycle=10 (it affects more of the video than cycle=5), the play was nearly identical to QTGMC. So much so, that I've decided to employ InterFrame (supposedly better than FrameRateConverter) so that I can eliminate the moire effect, which cannot be done when QTGMC is used.

So, I can now handle these mixtures of odd duplicates, eliminate the moire effect, extend/correct the playing time, establish a more conforming fps (23.976), and sync the audio because of all the help in this thread by so many of you.

For those interested in seeing the full script:

Video=MPEG2Source("C:\xxx.d2v", cpu=0)
Audio=DirectShowSource("C:\xxx.ac3")
AudioDub(Video,Audio)
TFM(y0=160,y1=480,pp=5,micmatching=0,slow=2)
TDecimate(Cycle=10,CycleR=1)
AssumeFPS(24)
AudioSpeed(24.0,26.973,PitchCorrect=True,Info=False)
InterFrame(Preset="Medium", Tuning="Film", NewNum=24000, NewDen=1001, Cores=1)
VagueDenoiser(chromaT=0)
KNLMeansCL(a=1,h=2)
LimitedSharpenFaster(strength=100)
CropResize(0,0, 8, 0, -4, -0,InDAR=15.0/11.0,ResizeWO=True,Resizer="Lanczos4Resize")
Greyscale()
GradFun3()
ConvertAudioTo16bit()

[hello_hello]

FrameRateConverter is generally better than InterFrame.

[Danette]

FrameRateConverter is generally better than InterFrame.

Then I'll have to change.

I replied to your pm, but I don't see anything as having been sent. Did you get it?

[johnmeyer]

FrameRateConverter is generally better than InterFrame.
Then I'll have to change. Just so the OP understands, both FrameRateConverter and InterFrame use the code and/or the algorithms from MVTools2. FrameRateConverter attempts to reduce artifacts via masking. InterFrame doesn't really add anything to the quality of the motion estimation and instead was created to provide real-time, GPU-assisted motion estimation so you can change 24p to 60p and get the "soap opera effect" while watching movies, without having to encode offline. InterFrame was optimized for that one task and is quite limited and doesn't attempt to do all the other things that you can do with MVTools2 (like noise reduction).

So, while I certainly agree that the quality produced by FrameRateConverter is better than Interframe, I am not at all certain that it produces better quality than simply using MVTools2 itself. I participated quite a bit in the thread which led to the development of FrameRateConverter, and much of my work with MVTools2 was used as a sort of benchmark against which FrameRateConverter was measured. It definitely did produce good results in some cases, but also failed to produce any improvement in others, and occasionally produced worse output.

So, bottom line, I don't know if you'll see much improvement by changing, but by all means, if you have the time, try it out.