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 14th May 2020, 00:18   #141  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
PS -- All of the credits encodes you provided look truly phenomenal. I have to wait for the sun to go down before I can really proof dark-screen content on this system (Yeah, I know, goofy reason, but it's true), but they look gorgeous from what I can see.
JoelHruska is offline   Reply With Quote
Old 14th May 2020, 00:36   #142  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by zapp7 View Post
I'm a total noob when it comes to all of this. What I'm doing currently, based on comments upthread, is converting to RGB24 with the PC.601 matrix, then feeding into Topaz. I then convert the Topaz output back to YV12 using the PC.601 matrix. How would the 709 fit in to that? Also, I'm upscaling to 2160p, if that makes a difference.
PC.709 when going from your upscaled RGB images to YUV

(unless you were planning on using Rec2020. Many UHD productions still use 709 for legacy reasons)
poisondeathray is offline   Reply With Quote
Old 14th May 2020, 05:14   #143  |  Link
zapp7
Registered User
 
Join Date: May 2020
Location: Canada
Posts: 49
This MCDegrainSharp function is awesome! I applied it to the season 1 intro (which is horrible quality) and it looks way better. Is there any down side to applying this to the entire episode, aside from longer processing time?
zapp7 is offline   Reply With Quote
Old 14th May 2020, 05:48   #144  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by JoelHruska View Post
Apparently, calling "ffms2" instead of "FFVideoSource" will work in StaxRip, but I'm not sure it changes anything in the other errors when I do.

*pause*

Nope. Doesn't.

At any rate, apologies. I'll have to do some more surgery on the OS, clearly, before I can test any of this.

EDIT #2: I'm getting exactly the same error on Handbrake that I am on MakeMKV. I've tried both a CFR and a VFR MKV file ingest. Probably has something to do with using StaxRip as a front-end or having AviSynth+ installed instead of AviSynth.

The wrong framerate is probably from ffms2. You probably have jitter in the MKV timestamps

If you're using ffms2, FFVideoSource, you also need to set rffmode=1 to honor the repeat field flags .

But ffms2 is less reliable, less consistent than DGIndex, MPEG2Source. MPEG2Source is what everyone uses for DVD's. It's rock solid

To use DGIndex on a DVD MPEG2 in MKV, you'd have to demux it first. (DGSource will work on a MKV , but it requires a compatible Nvidia card and is not free)
poisondeathray is offline   Reply With Quote
Old 14th May 2020, 07:38   #145  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
Quote:
Originally Posted by JoelHruska View Post
There is no MCDegrainSharp. When I remove the call to that filter, StaxRip tells me "Splice - Video Frame Rate Doesn't Match."
Looks to me like you are saying that you dont have McDegrainSharp(), and when you comment it out you get wrong framerate warning.

I'm guessin' that what you have actually commented out are calls to IVTC_Denoise() which calls McDegrainSharp, if so then

Code:
# To IVTC the film sections with a bit of denoising
function IVTC_Denoise(clip Video)
{
Video.TFM().TDecimate().MCDegrainSharp()
}
If call to above commented out then no TDecimate and would indeed be mismatch in framerate. [commenting out MCDegrainSharp alone would not affect framerate]

Here is McDegrainSharp, try again without commenting out the filter.
https://forum.doom9.org/showthread.p...45#post1737045

Also, if above guesswork was correct, then maybe be a little more clear so as to avoid the guessin' bit.

EDIT:
Quote:
Originally Posted by zapp7 View Post
Is there any down side to applying this to the entire episode, aside from longer processing time?
I use it on pretty much everything (although mostly with Frames=1[default=2], and quite often csharp=0.3 [default=0.6]), downside ?, me dont think so, me likee

EDIT: I've also just added this edit to McDegrainSharp() post,
Quote:
EDIT: Perhaps McDegrainSharp() default bblur should also be raised a little for HD stuff.
__________________
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; 14th May 2020 at 08:21.
StainlessS is offline   Reply With Quote
Old 14th May 2020, 09:29   #146  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by JoelHruska View Post
Clearly I've got a lot of work to do before I can even attempt the scripts you've been kind enough to write. Multiple filters you call are, apparently, either invoked differently by StaxRip and the AviSynth+ installation it uses or must be downloaded and added. I've not had much luck doing this manually to-date.
First thing:
I discovered while writing these instructions that I messed up with the frame numbers. The CGI section should have ended on frame number 3714 (or 3175), not 3000. I'm not sure what happened there. Maybe I incorrectly used the frame number after IVTC, not before. I'll run another encode again later.

Also, if you compare the credits in the film section between my AnimeIVTC and KatieIVTC encodes, you see some of them "blink out" a little for the Katie encode whereas they're smoother in the other. Exactly the same IVTC was used for both though. I think the difference was starting the IVTC for the film section on a different frame number, which can effect the result, because the IVTC process works on groups of five frames. Theoretically, you'd keep the Trims to multiples of 5, or start a new Trim on a scene change, but I found adjusting the end/start frames up or down by a frame could change the result, especially in the CGI section (where the field order appears to change), so if there's jitter etc, that's something to try. Anyway...

MeGUI has an AVS cutter under the Tools menu. You create a script to open the source (MeGUI can do that from the File/Open menu) then save and open it with the AVS Cutter. It has a preview displaying the frame numbers, and you use it to set the start and end points for multiple instances of Trim. It looks a bit different to the way I've been doing it manually, but the result is the same.

This was the initial script:

Quote:
LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VTS_02_1_sample.d2v")

Crop(8,0,-8,0)
Using the AVS Cutter to add the first lot of Trims looks like this (MeGUI calls them "cuts").

Quote:
__film = last
__t0 = __film.trim(0, 65)
__t1 = __film.trim(66, 735)
__t2 = __film.trim(736, 3714)
__t3 = __film.trim(3715, 6858)
__t0 ++ __t1 ++ __t2 ++ __t3
As those cuts are going to be used to apply IVTC, they'll change the frame count, so if you want to add a second lot of cuts you need to add IVTC first. You can just add basic IVTC to make it fast if you want to, if all you're concerned about is the correct frame numbers after IVTC. In fact you could probably just leave the trims as they are and follow them with a single IVTC.

TFM().TDecimate()

If you want to add additional filtering that doesn't cover the same frame ranges as the previous Trims, you'd open the script in the AVS Cutter again and add a second lot of Trims. When you're done, save them to the script and edit it to add the appropriate filtering to each (also removing the temporary IVTC). After the Trims you can add additional filtering that'll apply to the whole video. In my case I just added some resizing and dithering.

Quote:
__film = last
__t0 = __film.trim(0, 65).IVTC_Denoise()
__t1 = __film.trim(66, 735).TFM().TDecimate()
__t2 = __film.trim(736, 3714).QIVTC()
__t3 = __film.trim(3715, 6858).IVTC_Denoise()
__t0 ++ __t1 ++ __t2 ++ __t3

# TFM().TDecimate() This line can now be removed

__film = last
__t0 = __film.trim(0,928)
__t1 = __film.trim(929, 1258).QTGMC_Repair()
__t2 = __film.trim(1259, 0)
__t0 ++ __t1 ++ __t2

Resize8(640,480)
GradFun3()
Quote:
Originally Posted by JoelHruska View Post
There is no MCDegrainSharp. When I remove the call to that filter, StaxRip tells me "Splice - Video Frame Rate Doesn't Match." I'm not sure why. StaxRip uses AviSynth+, not AviSynth, and some of the calls are different, but I don't know which.
As StainlessS said, you probably removed the IVTC with it, so the frame rates no longer match, and each spliced Trim must have the same frame rate.

Install AVisynth+ if you don't have it installed. You can put additional plugins and avsi functions in the "installed" Avisynth plugins folder. You could save the little functions from my earlier post with an avsi extension and put them in the "installed" Avisynth plugins folder too, if you wish. When a programs runs it's portable version of Avisynth, that folder is still checked, and any plugins/functions inside are automatically loaded, so you can just use them in scripts without having to load them first. And with Avisynth installed you can open scripts in other programs.
I assume StaxRip comes with it's own collection of plugins and functions which it loads in scripts as required, but using additional plugins/functions from the "installed" Avisynth plugins folder should work the way I described. I haven't used StaxRip for quite a while and I can't remember how to modify it's scripts or how easy that is.

I don't quite understand what you meant regarding the Handbrake error. Can Handbrake open Avisynth scripts these days?

Edit: Everything needs to be 64 bit or 32 bit, and I gather StaxRip is 64 bit these days? I'm using the 32 bit MeGUI, but there is a 64 bit version, and you'll probably have to install 64 bit Avisynth+ and use 64 bit plugins. You might be able to install 32 bit and 64 bit versions of Avisynth at the same time, and use 32 bit and 64 bit programs with them, each Avisynth installation with the appropriate 32 bit and 64 bit plugins. I'm not sure though. I'm still using XP. Someone else will no doubt be able to tell you.

Quote:
Originally Posted by JoelHruska View Post
I continue to learn things that are not particularly helpful. Apparently, calling "ffms2" instead of "FFVideoSource" will work in StaxRip, but I'm not sure it changes anything in the other errors when I do.
FFMS2 is FFVideoSource and FFAudioSource combined, but the audio is disabled by default.

The MCDeGrainSharp function can be found here:
https://forum.doom9.org/showthread.p...07#post1855907
I discovered it through StainlessS.

zapp7,
I use MCDeGrainSharp quite a bit, but only if there's light to medium noise, otherwise I'd use something else, but if you like the result, there's probably no downside.

I'll run another encode shortly with the correct Trim ranges to see what it looks like. That might fix the slight jitter I noticed somewhere towards the end of the CGI section.

Last edited by hello_hello; 14th May 2020 at 13:43.
hello_hello is offline   Reply With Quote
Old 14th May 2020, 09:46   #147  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
HH, NOTE that McDegrainSharp updated some time ago, [updated compared to your posted link, I update that linked post, whenever it may happen].

Again McDegrainSharp() here:- https://forum.doom9.org/showthread.p...45#post1737045
__________________
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 14th May 2020, 10:20   #148  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by StainlessS View Post
HH, NOTE that McDegrainSharp updated some time ago, [updated compared to your posted link, I update that linked post, whenever it may happen].

Again McDegrainSharp() here:- https://forum.doom9.org/showthread.p...45#post1737045
Am I missing something or did you leave TrueMotion enabled for that version?
hello_hello is offline   Reply With Quote
Old 14th May 2020, 10:56   #149  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
I did not touch TrueMotion,
remind me, was it suggested to turn off for HD, (cant remember, nor remember where was suggested).
I only changed default blocksize, and added Limit stuff as per hi-lites in BLUE.

Also should maybe (guessin) raise bblur default 0.6 where HD (due to the 'grittiness' of HD compared to SD). (by how much, dont know)

EDIT: Oops, I did not notice that you had changed TrueMotion in your link, I thought it was simple copy of original post.
I'll come back to the TrueMotion thing later (got to go shopping for beer and other necessities).
EDIT: Arh, that thread was where trueMotion was discussed, who knew
__________________
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; 14th May 2020 at 14:06.
StainlessS is offline   Reply With Quote
Old 14th May 2020, 11:14   #150  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by StainlessS View Post
I did not touch TrueMotion,
remind me, was it suggested to turn off for HD, (cant remember, nor remember where was suggested).
I only changed default blocksize, and added Limit stuff as per hi-lites in BLUE.

Also should maybe (guessin) raise bblur default 0.6 where HD (due to the 'grittiness' of HD compared to SD). (by how much, dont know)
Remember the screenshots in the TemporalDegrain2 thread where I compared MCDegrainSharp with and without TrueMotion? They were 720p.
https://forum.doom9.org/showthread.p...69#post1855869

Or the earlier comparisons, where QTGMC was looking more clever than TemporalDegrain2 because the latter had True Motion enabled?
https://forum.doom9.org/showthread.p...55#post1855055

They were the inspiration for my McDegrainSharp mod to disable it (the version I linked to).

Edit: I missed your edit before posting so now I'm repeating what you know.

I'm fairly sure it's disabled for resolutions above SD in SMDegrain and I think the default is disabled for MCTD, regardless of resolution, but it might pay to check. I can't remember when QTGMC enables it, but I'm sure the default is disabled. QTGMC mightn't have an argument to change it directly as such. It might be tied to another setting or a preset. I can't remember.

Last edited by hello_hello; 14th May 2020 at 11:22.
hello_hello is offline   Reply With Quote
Old 14th May 2020, 13:27   #151  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
I don't know what I was thinking. A milder QTGMC repair over the whole CGI section is worth a tiny bit of lost detail, in my opinion.

A new sample, only requiring one set of Trims as the QTGMC repair is included in the QIVTC function. The QTGMC repair "may" look smoother due to the additional motion blur arguments.

Quote:
function QIVTC(clip Video)
{
DeintClip = Video.TFM(Mode=6, PP=1, MI=20, Slow=2, CThresh=4).QTGMC().SelectEven()
Video.TFM(Mode=6, Clip2=DeintClip, MI=20, Slow=2, CThresh=4).TDecimate()
QTGMC(Preset="Very Slow", InputType=1, ShutterBlur=3, ShutterAngleSrc=180, ShutterAngleOut=180, SBlurLimit=8)
}
Quote:
function IVTC_Denoise(clip Video)
{
Video.TFM().TDecimate().MCDegrainSharp()
}
Quote:
DGDecode_mpeg2source("D:\VTS_02_1_sample.d2v")
Crop(8,0,-8,0)

Trim(0,65).IVTC_Denoise() ++ \
Trim(66,735).TFM().TDecimate() ++ \
Trim(736,3714).QIVTC() ++ \
Trim(3715,0).IVTC_Denoise()

Resize8(640,480)
GradFun3()
As an experiment, I modified the Katie method again to see how it'd compare if I gave it better de-interlaced clips to use. It's slow, as it has to de-interlace twice with QTGMC before repairing with QTGMC, whereas the more normal IVTC method only de-interlaces once, but where the CGI fades from one shot to another and the field order changes there are differences. I think the more standard IVTC generally looks a bit smoother through those transitions, but I've watched them so many times I can barely remember my name, so I've uploaded both encodes in case anyone else wants to look. The sort of transition I'm referring to is the fade from one shot to the next, a little bit after frame number 1800. The transition just after frame 2300 looks smoother for the Katie Mod encode, but I'm not sure that's always the case.

This is what I used as a modified version of the Katie method for IVTC in the CGI sections.

Quote:
function QIVTC(clip Video)
{
A = Video.Tfm(field=0,mode=0, PP=1, MI=20, Slow=2, CThresh=4, Micmatching=0).QTGMC().SelectEven()
B = Video.Tfm(field=1,mode=0, PP=1, MI=20, Slow=2, CThresh=4, Micmatching=0).QTGMC().SelectEven()
C = Video.Tfm(field=0,mode=0, MI=20, Slow=2, CThresh=4, Clip2=A, Micmatching=0)
D = Video.Tfm(field=1,mode=0, MI=20, Slow=2, CThresh=4, Clip2=B, Micmatching=0)
Interleave(C,D)
TDecimate(mode=7, rate=24.0/1.001).AssumeFPS(24000,1001)
QTGMC(Preset="Very Slow", InputType=1, ShutterBlur=3, ShutterAngleSrc=180, ShutterAngleOut=180, SBlurLimit=8)
}
Both encodes can be download here.

Last edited by hello_hello; 14th May 2020 at 13:33.
hello_hello is offline   Reply With Quote
Old 14th May 2020, 14:15   #152  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
Quote:
Also, if above guesswork was correct, then maybe be a little more clear so as to avoid the guessin' bit.
I do not know how I could possibly have been more clear than "I removed the call to that filter." Previously, there was a call to that filter. I removed it.

Specifically, I changed the following line of code:

Quote:
F = Clip.TFM().TDecimate().MCDegrainSharp()
to the following:

Quote:
F=Clip.TFM().TDecimate()
This produces the video splice error.

I will quote my code changes in the future to avoid the ambiguity.
JoelHruska is offline   Reply With Quote
Old 14th May 2020, 14:56   #153  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
Hello Hello,

Sorry for the ambiguity. References to Handbrake and MakeMKV in the same sentence should be read as a reference to using Handbrake or MakeMKV-derived source. I apologize for being unclear and will change how i refer to this in the future.

The reason I referenced both applications is because I was having the weird problem with MakeMKV playback speed in the first place. I wanted to make it clear that I tested both a CFR and a VFR ingestion of the file, and got the same "incorrect speed" error on both, in order to illustrate that the problems were unconnected.
JoelHruska is offline   Reply With Quote
Old 14th May 2020, 16:54   #154  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
Attempting to use MPEG2Source instead of FFVideoSource produces the following error in StaxRip: "Invalid D2V File, It is Empty!"

So, obviously I need to create a D2V file for each MKV if I want to use MPEG2Source.
JoelHruska is offline   Reply With Quote
Old 14th May 2020, 17:00   #155  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by JoelHruska View Post
This produces the video splice error.
MCDegrainSharp doesn't touch the frame rate.

I have a theory....
I assume you removed MCDegrainSharp because of a "no such function" error. Once that error was removed you worked your way up the error chain.

The following line was used because in mode 7, TDecimate can't always decimate to the exact frame rate. It's generally so close it doesn't matter, but Avisynth needs exact, so AssumeFPS adjusts it to the correct frame rate.

TDecimate(mode=7, rate=24.0/1.001).AssumeFPS(24000,1001)

This line will give you exactly the right frame rate (23.976), if the source frame rate is exactly right (29.97).

F = Clip.TFM().TDecimate()

If you opened the source with ffms2 without honouring the repeat flags, the source frame rate would be different, the "F" line above wouldn't have a frame rate of 23.976fps, instead it'd be relative to the source frame rate, while the earlier line would still be 23.976fps, because AssumeFPS told Avisynth to speed it up or slow it down to 23.976fps, regardless of the actual frame rate, so removing MCDegrainSharp fixed the "no function" error, only to expose the frame rate mismatch when splicing.

That's my best guess, after letting the last bit of info rattle around in my head for a while, but only because the additional details made me realise you were talking about a different script than the one I (and StainlessS) thought you were referring to.

FFMS2/FFVideoSource needs it's RFFMode argument enabled to honour repeat flags. That way it should decode the video ripped with MakeMKV at 29.97fps. ie

FFVideoSource("E:\VTS_02_1.mkv", RFFMode=1)

For LSmash, I think the latest version has it's repeat option enabled by default, but if not, or for older versions, it's Repeat=true instead.

DGIndex honours repeat flags, which is one of the reasons it's the recommended method for mpeg2 video, but it can't open MKVs. If you remux the video from the MKV as a ts file with TSMuxer as I suggested, StaxRip will probably open the ts file with DGIndex.

I'm still not clear on the Handbrake part. As far as I know it's CFR/VFR choice only effects the output. It should handle the input from VFR a MKV correctly. If you have the correct filters enabled (the Decomb filter I think, I don't use Handbrake) it should output a VFR if you tell it to.
In fact for Handbrake it's probably the best choice. If the input is VFR (combinations of interlaced/hard telecine and soft telecine) and the filtering is enabled, it'll decimate and de-interlace as normal, but if you tell it to output a constant frame rate of 29.97fps (for example), the interlaced parts will be okay, but the film parts will have lots of duplicate frames to increase the frame rate to 29.97fps, and that generally looks terrible because motion gets quite choppy. For hybrid sources it's generally better to let it output a VFR. If you want to use the output as the input for another program though....

Last edited by hello_hello; 14th May 2020 at 17:30.
hello_hello is offline   Reply With Quote
Old 14th May 2020, 17:23   #156  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Quote:
Originally Posted by JoelHruska View Post
Attempting to use MPEG2Source instead of FFVideoSource produces the following error in StaxRip: "Invalid D2V File, It is Empty!"

So, obviously I need to create a D2V file for each MKV if I want to use MPEG2Source.
When ffms2 indexes, it creates an index file with an ffindex extension. For Lsmash it's LWI and for DGIndex it's D2V. They're not interchangeable. StaxRip probably does it for you but DGIndex can't index MKVs.

After DGIndex has created an index file it's opened by DGDecode with mpeg2source. They're two separate programs but designed to work together. The index file is normally created by a GUI via the command line, as they can't run DGIndex via a script, although DGIndex has it's own GUI. The index files are normally opened directly as they contain the location of the source file:

mpeg2source("D:\VTS_02_1.d2v")

For ffms2 and lsmash it's an Avisynth plugin to both index and decode. If you open a file with either and there's no index file, they'll create one automatically.

FFVideoSource assumes the index file is in the same folder as the source. If it's not you can use the cache argument.

FFVideoSource("E:\VTS_02_1.mkv", RFFMode=1, cachefile="D:\SomeFolder\VTS_02_1.ffindex")

For LSmash you can do it either way these days. If you were to open an MKV it'd look for an lwi index file in the same folder. If it doesn't find one it'll index, unless you use it's cache argument, but you can also open index files directly as they contain the location of the source file.

LWLibavVideoSource("D:\VTS_02_1.lwi")

You need to remux the MKVs as TS files so StaxRip can open them instead, index with DGIndex and create a script to decode with mpeg2source, if you want to use DGIndex/DGDecode (unless you have the DVD files ripped and handy). I assume that's how StaxRip will open TS files, but it can't open MKVs with DGIndex/mpeg2source.

There's newer versions of DGIndex that can index MKVs and use a video card to decode rather than your CPU. I think DGIndexNV and DGDecNV are the Nvidia versions. I don't know a lot about them, but StaxRip probably supports the current ones. They're pretty cheap, but they're not free. http://rationalqm.us/dgdecnv/dgdecnv.html

Last edited by hello_hello; 14th May 2020 at 22:34.
hello_hello is offline   Reply With Quote
Old 14th May 2020, 18:02   #157  |  Link
videoh
Useful n00b
 
Join Date: Jul 2014
Posts: 1,667
Quote:
Originally Posted by hello_hello View Post
I think DGIndexNV and DGDecNV are the Nvidia versions. I don't know a lot about them, but StaxRip probably supports the current ones. They're pretty cheap, but they're not free. http://rationalqm.us/dgdecnv/dgdecnv.html
Yes, they will index and frame serve MKV. I believe they can be used in staxrip, but they are not bundled in staxrip.
videoh is offline   Reply With Quote
Old 14th May 2020, 22:37   #158  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
Hello_Hello,

Your assumption was accurate. I removed the call out to McDegrainSharp because of the error calling it created. I have managed to get your initial script (the one from back on Page 7) to run properly, though I had to remove the "resize8" command (don't have that filter installed at the moment, either, though I'll see about getting it).

I have a question for you.

Allowing for the fact that different people perceive quality differently, it has always been obvious that any effort to create the best possible version of Deep Space 9 or any other TV show would require scene-by-scene or frame-by-frame editing. I do not dispute this. Your version(s) of the credits are all better than what I'd produced.

My original goal, however, was not to create a scene-by-scene scripted guide to how to restore DS9. I do not believe I can afford the time required to painstakingly create a scene-by-scene idealized repair for every single episode -- and that assumes I had the skill to do so. I currently do not.

Here, then, is my question:

How would you approach the question of improving the DVD source if your goal was to improve as much of the underlying content as possible a relatively broad (though lightly applied) brush?

I realize this question may stand very much opposite to the way things are done, and I'm interested in exploring the type of repair you do at the scene-level and frame-level. This kind of low-level manipulation is incredibly interesting. But I do want to make sure that the project I've taken on strikes a balance between difficulty of setup (because I want people to be able to follow a tutorial), total processing time (obvious reason, if it hasn't been a concern for me personally to-date) and then the total difficulty of creating the tutorials in the first place, which lands on my shoulders.

I know that a lighter touch is always better on all but the most mucked-up video. Is it possible to find some light touches that can be run across the entire encode to repair various issues without causing the QTGMC impacts you dislike?
JoelHruska is offline   Reply With Quote
Old 14th May 2020, 23:24   #159  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
One thing before replying.... I looked at my last encodes again and I think the last modification of the Katie method for IVTC of the CGI section produces the smoothest result. I thought her method looked a bit awful originally (it did) but after experimenting and changing the dienterlaced clips it uses I think it's a little smoother through the fades between shots. The difference is very small, but that's probably the method I'd go with. Anyway....

The idea isn't so much to inspect every scene and apply scene specific filtering, it was to find a good way to IVTC the CGI stuff compared to the rest, assuming all the CGI has similar problems. I gather most episodes will predominantly be film, where standard IVTC can be applied, so if it was me, I would go through each episode (probably with MeGUI's AVS Cutter) and specify Trims to divide a script into film and CGI sections. I've done that sort of thing a lot myself. Once you've saved the Trims it's then easy to apply the same IVTC to each CGI section and the same IVTC to the film sections. You shouldn't need to create a new method of IVTC each time. That part's done now. That's the theory at least, having only seen one sample, but I think putting the extra time into creating the scripts in order to have a nice, clean CFR output will save you time and grief later.

I don't dislike using QTGMC to clean up video, I often run it in progressive mode for DVD sources to denoise, but I use it for that because often DVD video isn't very clean/stable, and as well as denoising, QTGMC can help with that. I'd run something like this over an entire video fairly regularly, even HD sources at times.

QTGMC(InputType=1, EzDenoise=1.5)

I just thought the two instances you were using to repair the CGI were a bit over the top and creating "mush" for want of a better word.

In the case of Deep Space Nine, the picture in the film sections is very stable, from what I've seen. There's a bit of noise, but the underlying picture is quite good. I did try running QTGMC on it at one stage rather than MCDegrainSharp, but the picture itself doesn't need stabilising, just some noise removal, so in this case I thought MCDegrainSharp looked better. Hopefully that makes sense. Aside from the horrid CGI, I haven't seen any issues in other sections yet. If the sample we've been playing with is any indication, standard IVTC and MCDegrainSharp will be fine for all the film sections.

In case it gets lost in the thread, here's the function to IVTC the CGI sections, assuming you want to split the scripts into CGI and film sections with Trim. It's the heavily modified Katie method, and a bit slow, but based on the sample, I think it'll be the best "one size fits all" method of dealing with the CGI parts.

Quote:
function QIVTC(clip Video)
{
A = Video.Tfm(field=0,mode=0, PP=1, MI=20, Slow=2, CThresh=4, Micmatching=0).QTGMC().SelectEven()
B = Video.Tfm(field=1,mode=0, PP=1, MI=20, Slow=2, CThresh=4, Micmatching=0).QTGMC().SelectEven()
C = Video.Tfm(field=0,mode=0, MI=20, Slow=2, CThresh=4, Clip2=A, Micmatching=0)
D = Video.Tfm(field=1,mode=0, MI=20, Slow=2, CThresh=4, Clip2=B, Micmatching=0)
Interleave(C,D)
TDecimate(mode=7, rate=24.0/1.001).AssumeFPS(24000,1001)
QTGMC(Preset="Very Slow", InputType=1, ShutterBlur=3, ShutterAngleSrc=180, ShutterAngleOut=180, SBlurLimit=8)
}
hello_hello is offline   Reply With Quote
Old 15th May 2020, 00:36   #160  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,823
Something important.... that I wasn't thinking about while testing..

If you do divide the script into film and CGI sections, the IVTC process converts five telecined frames into four progressive frames. When you IVTC a whole video that's fine, but when you divide the video up into sections the way I've been doing it for testing, you risk losing a frame in each section, unless you stick to multiples of five for each Trim. Here's a quick example:

This Trim contains 100 frames and at 29.97fps, it's duration is 4 sec 170ms.
Trim(0,99)
Apply IVTC and it now only contains 80 frames at 23.976fps but the duration is the same.
Trim(0,99).TFM()TDecimate()

This Trim contains 101 frames and it's duration is 4 sec 212ms.
Trim(0,100)
After IVTC it contains 80 frames and it's duration drops to 4 sec 170ms
Trim(0,100).TFM()TDecimate()

Sometimes you might create a frame, but with lots of trims the errors could add up and effect the audio sync.
I just checked the effect of the trims I added to the sample, as they weren't multiples of five, and they reduced the total duration by 90ms, which is unsatisfactory, so either stick to exact multiples of five for Trims used for IVTC, or do it by creating two clips instead.

First, add basic IVTC to a script, then add the trims.

TFM()TDecimate()

Trim(0,62) ++ \
Trim(63,715) ++ \
Trim(716,3682) ++ \
Trim(3683,0)

Replace the basic IVTC with two IVTC'd clips, then modify the Trims to splice the clips correctly.

SomeVideoSource()
Video = last
Clip1 = Video.QIVTC() # The CGI IVTC function is applied to the whole clip.
Clip2 = Video.IVTC_Denoise() # Standard IVTC and denoising function is applied to the whole clip.

Clip1.Trim(0,62) ++ \
Clip2.Trim(63,715) ++ \
Clip1.Trim(716,3682) ++ \
Clip2.Trim(3683,0)

It's a bit more work, but you can pick any frame range for the Trims without worrying about audio sync because IVTC has already been applied. I should have been thinking about that from the start... well I did it that way for the first few scripts I posted, then I got lost in the IVTC tests and forgot....but I really thought I should point this out.

Last edited by hello_hello; 15th May 2020 at 00:54.
hello_hello 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 21:13.


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