Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 16th January 2021, 17:10   #21  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
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.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 16th January 2021 at 17:38.
StainlessS is offline   Reply With Quote
Old 16th January 2021, 17:57   #22  |  Link
Danette
Registered User
 
Join Date: Apr 2013
Posts: 346
Quote:
Originally Posted by StainlessS View Post
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.

Last edited by Danette; 16th January 2021 at 21:01.
Danette is offline   Reply With Quote
Old 16th January 2021, 18:09   #23  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,667
Quote:
Originally Posted by StainlessS View Post
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.

Last edited by videoh; 16th January 2021 at 18:12.
videoh is offline   Reply With Quote
Old 16th January 2021, 20:14   #24  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
That will do nicely, thanks very much.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???
StainlessS is offline   Reply With Quote
Old 16th January 2021, 22:42   #25  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
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)]
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 16th January 2021 at 22:49.
StainlessS is offline   Reply With Quote
Old 17th January 2021, 08:45   #26  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
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....

Last edited by hello_hello; 17th January 2021 at 09:53.
hello_hello is offline   Reply With Quote
Old 17th January 2021, 10:39   #27  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
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.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 17th January 2021 at 10:42.
StainlessS is offline   Reply With Quote
Old 17th January 2021, 16:35   #28  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
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.

Last edited by hello_hello; 17th January 2021 at 16:43.
hello_hello is offline   Reply With Quote
Old 17th January 2021, 16:58   #29  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
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-ne...-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-i...5/?ito=cbshare
Quote:
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.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 18th January 2021 at 11:56.
StainlessS is offline   Reply With Quote
Old 18th January 2021, 05:53   #30  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
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.

Last edited by hello_hello; 18th January 2021 at 06:26.
hello_hello is offline   Reply With Quote
Old 22nd January 2021, 04:02   #31  |  Link
Danette
Registered User
 
Join Date: Apr 2013
Posts: 346
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.
Danette is offline   Reply With Quote
Old 22nd January 2021, 08:20   #32  |  Link
johnmeyer
Registered User
 
Join Date: Feb 2002
Location: California
Posts: 2,691
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)
johnmeyer is offline   Reply With Quote
Old 22nd January 2021, 10:50   #33  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
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.

Last edited by hello_hello; 22nd January 2021 at 20:03.
hello_hello is offline   Reply With Quote
Old 22nd January 2021, 14:37   #34  |  Link
Frank62
Registered User
 
Join Date: Mar 2017
Location: Germany
Posts: 234
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.
Frank62 is offline   Reply With Quote
Old 23rd January 2021, 02:16   #35  |  Link
Danette
Registered User
 
Join Date: Apr 2013
Posts: 346
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.

Last edited by Danette; 23rd January 2021 at 03:12.
Danette is offline   Reply With Quote
Old 23rd January 2021, 09:21   #36  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
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.

Last edited by hello_hello; 23rd January 2021 at 09:57.
hello_hello is offline   Reply With Quote
Old 23rd January 2021, 11:05   #37  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,997
Quote:
Originally Posted by Danette View Post
.....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.
Sharc is offline   Reply With Quote
Old 23rd January 2021, 16:28   #38  |  Link
Danette
Registered User
 
Join Date: Apr 2013
Posts: 346
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.
Danette is offline   Reply With Quote
Old 23rd January 2021, 19:02   #39  |  Link
Frank62
Registered User
 
Join Date: Mar 2017
Location: Germany
Posts: 234
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.
Frank62 is offline   Reply With Quote
Old 23rd January 2021, 20:53   #40  |  Link
Danette
Registered User
 
Join Date: Apr 2013
Posts: 346
“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.
Danette is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 18:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.