Avisynth/Vegas interface, other (new to avisynth) processing issues [Archive]

View Full Version : Avisynth/Vegas interface, other (new to avisynth) processing issues

Pages : [1] 2

Bruce/Fl

5th March 2016, 03:47

"Warning: An error occured while opening one or more files.

An error occurred while opening a codec"

That is the message I got when trying to open up a frameserved video into a second instance of Vegas.

I did some corrections on a ProRes442 video in Vegas 13 Pro, (debug) frame served it out, then after using AVFS and avisynth, tried to open up the resulting file back into Vegas, and got the text above in a trouble box.

I was trying John Meyers script when it happened, but that's not the cause, because I then also tried the degraining script I hashed out here with your help a few months ago, a script that I had success with using the same process I just laid out. But now, it gives me the same text in the trouble box.

Mediainfo says the codec at the avi in the volumes folder (from AVFS) has a codec ID of "YV12", the codec info is "ATI YVU12 4:2:0 Planar"

What went wrong? What do I need to do to make it work again? Any ideas? Any further info needed for assistance? I have no idea what changed from a little while ago when everything worked. I added some dll's for Johns script, but that was it.

Thank you

poisondeathray

5th March 2016, 03:50

IIRC I think vegas needs RGB for AVFS import , so add either ConvertToRGB32() or ConvertToRGB24() with the appropriate matrix (probably Rec709 for HD, unless you've done some round about processing)

Bruce/Fl

5th March 2016, 04:15

IIRC I think vegas needs RGB for AVFS import , so add either ConvertToRGB32() or ConvertToRGB24() with the appropriate matrix (probably Rec709 for HD, unless you've done some round about processing)

Thank you for the quick reply!

Yes, I just went back to an AVFS thread (http://forum.doom9.org/showthread.php?p=1737687#post1737687) I popped into when I was getting this all hashed out, and that was suggested to me. Apparantly I made the same mistake before, fixed it, and forgot what I did.

I stuck the "ConvertToRGB24()" in the script here, line 8 I think it would be. Is that the right place for it? It worked.

source=AVISource("C:\Users\Bruce\Desktop\fs.avi").selecteven().converttoYV12().killaudio
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
ConvertToRGB24()
final=assumefps(15/1.001)
return final

Now, whether to use the 24 or the 32? I am not that well versed by far in making that call. And the rest, about the matrix and the Rec509? Way beyond my understanding at this time. If you feel like educating me, I'd appreciaste it. Just use somewhat simple words, heh.

I don't think I did any "round about processing", just the script above, and trials with John Meyers script.

And speaking of his script, where would I stick that "convert toRGB" command in his script to get his working for me also. It is very complex, at least to my eyes.

John has been very, very kind and has been helping me when I ask, but sometimes I feel like I impose on him too often.

Here's his script. (http://forum.doom9.org/showthread.php?p=1595608#post1595608)

poisondeathray

5th March 2016, 04:48

Bruce/Fl

5th March 2016, 05:13

RGB24 vs. RGB32 just means without or with alpha channel. If 24 works, use that. It's been a while since I used AVFS for vegas, but some programs require 32 for alignment purposes or some programming reason. Eitherway it's just a "dummy" alpha channel in your case

The "roundabout" means about different things you might have done that require other manipulations. The colors will be "off" slightly if you use the wrong processing, wrong matrix etc... If you have HD prores, and exported with DMFS in RGB mode, then you should be ok up to that point. But you used ConvertToYV12() in your avs script. That means Rec601 by default, so you should use ConvertToRGB24() the default instead of ConvertToRGB24(matrix="rec709") which would normally have been used for HD footage . If it looks ok in vegas, just carry on

I went back to my initial thread here, and I see where I had the option to use either YV12 or YUY2, to clear a problem with the script. It said: "MSuper: Clip must be YV12 or YUY2". Video Fred chimed in and gave me a line of code to fix it, he selected YV12 in his example, so I went with it.

Would YUY2 have been a better choice? It sounds like what I included, the YV12 made it non HD. Should I have went with YUY2 and then used ConvertToRGB24(matrix="rec709")?

poisondeathray

5th March 2016, 17:28

Bruce/Fl

6th March 2016, 09:47

Yes, YUY2 would be better. YUY2 is 4:2:2, same as your prores. YV12 is 4:2:0 . This means losing quite a bit of color information. For example, if you had 1920x1080 4:4:4, the U,V planes which hold the color difference channels would be 1920x1080. 4:2:2 would mean they are only 960x1080 (half in the horizontal). 4:2:0 would mean 960x540 (halved in both horizontal and vertical). This is called "chroma subsampling"

Thank you, I've never seen the details of what those stats meant, which is on me because I never took the time to look it up. The 8mm source scans I'm working with are 4.2.2. Not optimal, but could be worse.

As soon as you bring it into vegas, you're working in RGB. You want to avoid unnecessary colorspace conversions, because they are lossy. This is in addition to chroma subsampling. So going back and forth in/out of vegas is a not a good idea as you convert it back to RGB again - avoidable quality loss there in your workflow. As a general rule, once you're in a certain colormodel/colorspace, you should stay there as long as possible until you have to change it for your final delivery format(s)

My present workflow is Vegas for edits, and also for color and brightness corrections. Then avisynth to run John Meyers (based on VideoFreds) script, then back into Vegas for my various renders.

The script calls for a convert to YV12. I tried switching it to see what would happen, it didn't work, and the error log tells me that the issue is with: "RemoveGrain: only planar color spaces are supported". So it looks like YV12 is it. Down to 4.2.0 coming out of the script.

So you're telling me, and it makes obvious sense, that less in and out of Vegas would be better. So I'm wondering, can/should I start with the avisynth script and then do Vegas only once? Do the edits and corrections (after the file has went thru the script) in Vegas and then do the renders as well. Now down to Avisynth script and Vegas.

If that is a way to go, a smart way to go, my first thought was hosting the script in Virtualdub. (Because that's what I started my initial tries at avisynth scripts with).

I know that there are other programs that I could use for the script. Is there a better choice?

There are ways to use YUV filters on RGB sources in avisynth, while staying in RGB, but they are much slower to process. Basically you copy the R,G,B and treat them as Y planes for filtering. This is detailed in other threads.

If I end up going with what I just outlined, this wouldn't be necessary would it? My source (ProRes422) is YUV, the script requires YV12, so I need to do a RGB conversion to get it into Vegas for the work I need to do there, if I understand correctly.

Does my new workflow look better? I would think it was, but I'm far from an expert. And if it is, suggestions on what program to run the script with?

poisondeathray

6th March 2016, 18:04

Thank you, I've never seen the details of what those stats meant, which is on me because I never took the time to look it up. The 8mm source scans I'm working with are 4.2.2. Not optimal, but could be worse.

My present workflow is Vegas for edits, and also for color and brightness corrections. Then avisynth to run John Meyers (based on VideoFreds) script, then back into Vegas for my various renders.

Yes, from a quality standpoint that would be better if you can group your avisynth manipulations either before or after. Or group all your vegas manipulations together. You don't want to incur additional unnecessary quality loss. It's not jumping through hoops, or spending 100x longer - just simple grouping of tasks

I guess the question is why did you need to go back into vegas if you were just there ? Is it only to encode to various formats ? What are your final format(s) ? There are other options to encode

So you're telling me, and it makes obvious sense, that less in and out of Vegas would be better. So I'm wondering, can/should I start with the avisynth script and then do Vegas only once? Do the edits and corrections (after the file has went thru the script) in Vegas and then do the renders as well. Now down to Avisynth script and Vegas.

If that is a way to go, a smart way to go, my first thought was hosting the script in Virtualdub. (Because that's what I started my initial tries at avisynth scripts with).

Yes it could work to do your avs script first, but then you already convert to 4:2:0 8bit prior to your colorwork in vegas. That is a no-no. Color manipulations will be better with more color information such as 10-bit 4:2:2 in the prores file to start with. So it would be better to use vegas first, avisynth last and use other encoders

If you're happy with this script, it makes more sense to finish it with avisynth and encode from the avs script, don't go back into vegas. There is no reason to. The encoders there are sub-par anyway for AVC, but decent for MPEG2 . If you were authoring with DVDA, the one scenario you might have to go back and use vegas' encoder is for interlaced AVC (DVDA has problems with x264 MBAFF)

I know that there are other programs that I could use for the script. Is there a better choice?

It depends on the project and what your goals/ final formats are. vdub is fine, but it mostly outputs AVI (you can use the external encoder function , but it has limitations) . If you're at the end of the project, it makes more sense to use the final encoder (e.g. lets say one of the formats is BD , you can use x264 directly. Quality is better than Sony or MC AVC too)

If I end up going with what I just outlined, this wouldn't be necessary would it? My source (ProRes422) is YUV, the script requires YV12, so I need to do a RGB conversion to get it into Vegas for the work I need to do there, if I understand correctly.

I would use ProRes directly in vegas as a first step. You have the full 10bit 4:2:2 at your disposal. Vegas as a host can work in 32bit float. There is no good reason to drop it down to 8bit 4:2:0 for color work

Bruce/Fl

6th March 2016, 21:18

I guess the question is why did you need to go back into vegas if you were just there ? Is it only to encode to various formats ? What are your final format(s) ? There are other options to encode

Yes, the sole reason for going back to vegas was to render out. At present, I want to fix the files as best I can, then output to BD for myself, and DVD for other family members who (for a variety of reasons) haven't made the jump to HD.

I might also later toy around with leaving the file in a format closer to native that I could put on a memory stick and play on my Panny Plasma, just to see. (I don't know the format that it accepts right off hand)

(My situation is this. I had some old family 8mm films scanned by Cinepost. Frame accurate. Outputted in ProRes422, 1920x1080. It looks like it was shot at 16fps originally, Cinepost slowed it down to 15, then doubled the frames, for 30fps (or 29.97) output. The speed seems fine to me, no tweaking needed in that regard.)

Yes it could work to do your avs script first, but then you already convert to 4:2:0 8bit prior to your colorwork in vegas. That is a no-no. Color manipulations will be better with more color information such as 10-bit 4:2:2 in the prores file to start with. So it would be better to use vegas first, avisynth last and use other encoders

If you're happy with this script, it makes more sense to finish it with avisynth and encode from the avs script, don't go back into vegas. There is no reason to. The encoders there are sub-par anyway for AVC, but decent for MPEG2.Already mentione dabove, but yes, BD is one of my goals. So that sounds good.

I'm very happy with the script, I can see very positive differences already, and I left pretty much everthing at the defaults. I did change the output size to fit my needs (script was setup for DV) and also adjusted the crop values accordingly to temporarily remove the pillar boxes so the depan would work properly.

It depends on the project and what your goals/ final formats are. vdub is fine, but it mostly outputs AVI (you can use the external encoder function , but it has limitations) . If you're at the end of the project, it makes more sense to use the final encoder (e.g. lets say one of the formats is BD , you can use x264 directly. Quality is better than Sony or MC AVC too)

I would use ProRes directly in vegas as a first step. You have the full 10bit 4:2:2 at your disposal. Vegas as a host can work in 32bit float. There is no good reason to drop it down to 8bit 4:2:0 for color work

Already mentioned above, but yes, BD is one of my goals, along with DVD. So that sounds good. Vegas first, at full 10bit 4:2:2 strength, then avisynth.

Which opens up some new questions for me. What would I render out of Vegas to, to give the best source to put into Avisynth? And what program to use to run the script? (Did I tell you I'm just now getting into this avisynth stuff?)

Also, I'll need to do some research to get up to speed on this "32 bit float" aspect of Vegas. Never used it, never really knew what it was for. I think I saw that option under "pixel format" when you look at "project properties". If that is it, is it the "Video levels" or the "full range" option?

Thank you again for your input.

poisondeathray

6th March 2016, 22:04

I might also later toy around with leaving the file in a format closer to native that I could put on a memory stick and play on my Panny Plasma, just to see. (I don't know the format that it accepts right off hand)

Definitely archive the original Prores scans. Your Panny won't play prores. No TV will , that's 100% certain

Which opens up some new questions for me. What would I render out of Vegas to, to give the best source to put into Avisynth? And what program to use to run the script? (Did I tell you I'm just now getting into this avisynth stuff?)

Also, I'll need to do some research to get up to speed on this "32 bit float" aspect of Vegas. Never used it, never really knew what it was for. I think I saw that option under "pixel format" when you look at "project properties". If that is it, is it the "Video levels" or the "full range" option?

It' s going to depend on the project and assets. But likely you have prores but scanned "normally" . So typically you would use video levels for that. Sometimes an asset is done in a special manner with log or linear curves - in that case you would normally use full range with a linear gamma

32bit is more accurate for intermediate calculations and manipulations - there is less rounding error. You introduce less banding with your color manipulations, compositing and layer blend modes are more accurate. The main "negative" to using 32bit processing is speed.. It's much slower. For many types of projects, 8bit manipulations are perfectly fine. So it's going to depend on your project specifics and expectations.

But you typically want to avoid 8bit processing whenever you can (especially since you're starting with true 10bit scans) - there are only 0-255 values per channel for 8bit formats, which is quite a bit of a loss in precision. 10bit has 0-1023 (but in "official" prores implmentations, it's effectively only 64-940 - but that's still a lot better than 0-255, or 16-235 if you've "legalized" the YUV values)

We are not allowed to use the "b" word here, so "ideal practices" would dictate you should export a higher bitdepth format from vegas, such as r10k, or r210 (these are 10bit 4:4:4) , or at least 10bit YUV 422 (v210) . Then take that and properly dither down to your final formats using dither tools. But the filesizes are massive and unwieldly with this workflow - they are uncompressed 10bit. dmfs only works in 8bit, but if using that I would use the RGB mode from vegas. But definitely I would do the color manipulations with 10bit 422. Reducing both the horizontal and vertical chroma resolution by 1/2 each , and lowering the precision to 8bit isn't a good starting point to begin with IMO.

So you have to decide what you want - do some mini-tests and see if it's worth going all out for you. You have to decide where you want to "cut corners". Some people might not have enough HDD space - DMFS definitely helps in those cases; others might not have time or want to put in the effort for the additional benefit in the final end result which might be miniscule in some cases.

Bruce/Fl

7th March 2016, 15:39

Definitely archive the original Prores scans.

I have the hard drive that they came back to me on, and I've got the files backed up on two more hard drives.

It' s going to depend on the project and assets. But likely you have prores but scanned "normally" . So typically you would use video levels for that. Sometimes an asset is done in a special manner with log or linear curves - in that case you would normally use full range with a linear gamma

I'm sure they were scanned "normally". I just wanted good copies (my father had them transferred to VHS in the late 80's, and I had one first gen copy and one second gen copy, they are brutal) that I could work on some in Vegas. I found out about Avisynth after seeing some samples of Video Freds and John Meyers work on 8mm stock right around the same time I had sent a roll in to Cinepost for a sample. My knowledge level of the processes involved in gettting those stunning results was close to nil at the time, it isn't much better as of today, but it is better.

32bit is more accurate for intermediate calculations and manipulations - there is less rounding error. You introduce less banding with your color manipulations, compositing and layer blend modes are more accurate. The main "negative" to using 32bit processing is speed.. It's much slower. For many types of projects, 8bit manipulations are perfectly fine. So it's going to depend on your project specifics and expectations.

But you typically want to avoid 8bit processing whenever you can (especially since you're starting with true 10bit scans) - there are only 0-255 values per channel for 8bit formats, which is quite a bit of a loss in precision. 10bit has 0-1023 (but in "official" prores implmentations, it's effectively only 64-940 - but that's still a lot better than 0-255, or 16-235 if you've "legalized" the YUV values)

Well, my scans (covered the specs already) are based on 8mm film my dad shot, mostly in the 60's and 70's. Probably regular stock Kodachrome, maybe later KodachromeII? His camera was a solid but not fancy Keystone. I'd like to get the resulting files to look as close to the subject matter as possible, the peculiarities of the special "Kodachrome look" notwithstanding.

We are not allowed to use the "b" word here, so "ideal practices" would dictate you should export a higher bitdepth format from vegas, such as r10k, or r210 (these are 10bit 4:4:4) , or at least 10bit YUV 422 (v210).

r10k, r210? Ok, not a clue. I just googled them both, looks like the r210 is a blackmagic codec? (I think I have it, I downloaded alot of them when I was trying to open up some of the various encodes that Cinepost sent me, they sent a variety) Nothing of r10k except a posters username somewhere. I'm going to need some good guidance on this aspect. Selecting and implementing. I'm guessing it might be selectable in a Vegas template? I've never customized a template yet.

Then take that and properly dither down to your final formats using dither tools. But the filesizes are massive and unwieldly with this workflow - they are uncompressed 10bit. dmfs only works in 8bit, but if using that I would use the RGB mode from vegas. But definitely I would do the color manipulations with 10bit 422. Reducing both the horizontal and vertical chroma resolution by 1/2 each , and lowering the precision to 8bit isn't a good starting point to begin with IMO.

So you have to decide what you want - do some mini-tests and see if it's worth going all out for you. You have to decide where you want to "cut corners". Some people might not have enough HDD space - DMFS definitely helps in those cases; others might not have time or want to put in the effort for the additional benefit in the final end result which might be miniscule in some cases.

How much HDD space would I need? I know when I tried some uncom pressed outputs from VirtualDub they were roughly 10 times the size of the source? Luckily I was only doing small samples. I finally started to use the Cineform 10bit codec on them, that brought the size in line. (I wasn't looking for full color palate final products, I was practicing with deshaker.)

On my desktop, the main C drive is a 500GB. I also have an internal 2TB drive with almost 1TB free. I have a 1.5 TB Ext with about 500GB free, and another 5TB Ext with almost 3TB free.

I'll probably pick up another 5TB Ext, because, redundancy. It would be mostly clear.

For my files, I have a quantity of 11. They range from 17 minutes (25GB) to 42 minutes (63GB) All together they come in at 1TB.

My new laptop (better processor than my desktop) has a 128GB main SSD(rive) and a 1TB additional internal drive. About 800 GB still open on that.

___________________________________________________________

I'd thought I'd put them on BD for my own use, some family members want DVDs.

For my BD's, how much (how long) of a file should I expect to be able to fit on a standard 25GB disc, if I do end up using, as they say, "ideal practices"?

Also, should I rename this thread? It started out as me not being able to get a file back into Vegas. That has been solved many posts ago and it has taken a much different course.

Thank you

poisondeathray

7th March 2016, 18:38

Bruce/Fl

8th March 2016, 10:43

To get r10k or r210 out of vegas, it's under "quicktime MOV" . You need AJA Kona or Blackmagic codecs installed to access it. You can do it with AVI, but AVI usually isn't properly handled under windows at higher bitdepths. They come with the capture hardware, but I think there might be free version on their website. But these files are massive, yes, larger than the files from vdub. This is 10bit uncompressed, not 8bit uncompressed. v210 is suitable as well, and far more common in production work. You don't need external codec for that. That is accessed under uncompressed sony 10bit YUV AVI. Filesizes are still larger than the ones out of vdub, but smaller than the 10bit RGB variants.

"sony 10bit YUV AVI" - I couldn't find that under the render options.

"near lossless" alternatives would be cineform, dnxhd . Dnxhd would be similar to prores. But IIRC you posted some really grainy scans - dnxhd won't handle that very well. (Prores actually doesn't handle it well either unless you use the Pr4444 variant). Cineform at "filmscan2" will handle it, and you've used cineform before

The problem is cineform currently isn't handled at 10bit with avisynth properly. To do anything at >8 bit in avisynth, you need to used the "stacked" 16bit workflow. There are ways to load 10bit as stacked 16 into avisynth with l-smash and ffms2 (10bit hack version) , but not for cineform yet.

I was using the Cineform with VD in my Deshaker trials. Another codec I tried was the UtVideo Pro YUV422 10bit VCM. In that role it wouldn't work for me, it gave me this:

Couldn't find compatible format
Possible reasons:
* Codec may only support YUV
* Codec may be locked
* Codec might be decompression only

The other UtVideo codecs worked, but they were 420.

Is that a good option, that is if it would work in this role?

But I suspect you probably won't notice the difference on your type of content in the final 8bit end result if you just frameserved 8bit RGB, or exported an 8bit RGB format out of vegas

I'm thinking this as well. I have some experience with the DBFS, and it would keep my file size down as well.
I could try some of these more advanced options later. And who knows, one of the super skilled people here might come up with some code that might, for instance, make Avisynth play nice with the Cineform 10bit, and then I could try that.

All the real time consuming work, (the renders and script running will take time as well, but you can just let them do their thing) the splitting of scenes and then the corrections of those scenes, those time consuming tasks I'll still have records of saved with the .veg files. So at a later date I could load them up again along with the script with the settings I've selected and try new processes like the ones you mentioned, or possibly others as well.

But for the time being I'm thinking do the work in Vegas in the 10bit realm, then FS it out to the script.

Do you mean duration? You're limited by max bitrate and BD spec along with disc capacity. Just use a BD bitrate calculator, it's analgous to DVD bitrate calculators, but more overhead in the transport stream . There are a many factors that go into planning, menus, extras, etc... It's actually a quite complex question and answer.

Yes, I meant duration. What I am planning on is pretty bare bones. A menu isn't even necessary. I was going to use the 25mbps stream option when I was planning on rendering out from Vegas. That seems to be a popular option. I think I read where they *can* take 40mbps max, and maybe brief surges above that. I think I'd probably shoot for 30mbps? Or should I go more, would I need more?

At 25-30 mbps I should be able to get close to 2 hours on a 25GB BD?

Earlier you mentioned other encoders than what I was planning on using, which was Vegas. Knowing what it appears I will be doing, which one(s) would suit my purposes?

Thank you

poisondeathray

8th March 2016, 16:26

"sony 10bit YUV AVI" - I couldn't find that under the render options.

It's slightly different under different vegas vesions, but in 13, it's under "video for windows". Select one of the HD YUV templates (e.g. HD 1080p-24 YUV) , then press customize template. Besides making sure all the parameters are correct for your project (e.g. framerate, dimensions, etc...) it's going to be under video format, there is a drop down menu with options. It's called "Sony 10bit YUV Codec" in vegas. Besides prores, v210 is one the more common intermediates in post production work, because that's what you get when you decode prores: 10bit 422 uncompressed YUV

I was using the Cineform with VD in my Deshaker trials. Another codec I tried was the UtVideo Pro YUV422 10bit VCM. In that role it wouldn't work for me, it gave me this:

Couldn't find compatible format
Possible reasons:
* Codec may only support YUV
* Codec may be locked
* Codec might be decompression only

Well deshaker requires RGB also - so where in the workflow was/is deshaker going to be?

The other UtVideo codecs worked, but they were 420.

Is that a good option, that is if it would work in this role?

UT Video supports 420,422,RGB, and 10bit422 as well (But very few programs if any treat the last one as true 10bit)

It's great for decompression speed (e.g. snappy editing), but it won't be as compressed as something like lagarith if filesize was your main consideration. MagicYUV is another good option

Yes, I meant duration. What I am planning on is pretty bare bones. A menu isn't even necessary. I was going to use the 25mbps stream option when I was planning on rendering out from Vegas. That seems to be a popular option. I think I read where they *can* take 40mbps max, and maybe brief surges above that. I think I'd probably shoot for 30mbps? Or should I go more, would I need more?

At 25-30 mbps I should be able to get close to 2 hours on a 25GB BD?

The maxrate for BD is 40Mbps. 30Mbps will be too much 25GB disc with 2hours - that even exceeds a container with almost no overhead like MKV. 25Mbps is cutting it closer, but it's going to depend on audio bitrate as well. You can get a rough ballpark idea by looking at various bitrate calculators (even non BD calculators will give you an underestimate, you can typically add 5-10% to get a rough approximation)

Earlier you mentioned other encoders than what I was planning on using, which was Vegas. Knowing what it appears I will be doing, which one(s) would suit my purposes?

Depends also on the authoring tool you plan to use. For progressive BD I would use x264. If you were using DVDA for AVC BD, you should know it doesn't work with MBAFF that x264 uses for field encoding. Progressive works fine. DVDA also has problems with higher bitrates

BD and DVD only supports specific frame rates, and your scans aren't one of them , so you also have to plan how to achieve that for compatibility - either some pulldown pattern either hard or soft.

For MPEG2 for DVD, many people would use HCEnc (Vegas's MPEG2 encoder by Mainconcept isn't that bad, but both Sony and MC AVC encoder bundled with vegas are terrible)

Bruce/Fl

8th March 2016, 17:01

It's slightly different under different vegas vesions, but in 13, it's under "video for windows". Select one of the HD YUV templates (e.g. HD 1080p-24 YUV) , then press customize template. Besides making sure all the parameters are correct for your project (e.g. framerate, dimensions, etc...) it's going to be under video format, there is a drop down menu with options. It's called "Sony 10bit YUV Codec" in vegas. Besides prores, v210 is one the more common intermediates in post production work, because that's what you get when you decode prores: 10bit 422 uncompressed YUV

I have 13 also, I'll look deeper. (I didn't go into the templates)

Well deshaker requires RGB also - so where in the workflow was/is deshaker going to be?

I was trying it out, seeing if I could get it to work. Getting used to doing various things to see if they would work for me/I was gaing an understanding.

Johns script does stabilization also, using depan. Deshaker is not in the workflow any longer.

The maxrate for BD is 40Mbps. 30Mbps will be too much 25GB disc with 2hours - that even exceeds a container with almost no overhead like MKV. 25Mbps is cutting it closer, but it's going to depend on audio bitrate as well. You can get a rough ballpark idea by looking at various bitrate calculators (even non BD calculators will give you an underestimate, you can typically add 5-10% to get a rough approximation)

The films are 8mm, silent. Thats how I am viewing them presently. I could add that typical background music old home movies get scored with, I haven't decided.

I'm not locked ino the 2 hour thing, if the file is too big for one disc at 25Mbps, I'll make it an hour and 45 minutes, or whatever it takes. Or if I add music and need trim the duration some, same plan.

Depends also on the authoring tool you plan to use. For progressive BD I would use x264. If you were using DVDA for AVC BD, you should know it doesn't work with MBAFF that x264 uses for field encoding. Progressive works fine. DVDA also has problems with higher bitrates

Progressive/x264 is fine.

BD and DVD only supports specific frame rates, and your scans aren't one of them , so you also have to plan how to achieve that for compatibility - either some pulldown pattern either hard or soft.

By using the "selecteven" command, Johns script outputs my file at 14.985. When I authored some straight (I didn't touch the files with any corrections or Avisynth scripts, just made copies for my sister till I could get her some "better" copies) DVD's earlier using Vegas, I disabled sampling and they outputed at the standard 29.97. Wouldn't that be one of the standard frame rates?

For MPEG2 for DVD, many people would use HCEnc (Vegas's MPEG2 encoder by Mainconcept isn't that bad, but both Sony and MC AVC encoder bundled with vegas are terrible)

So HCEnc would be a prpper tool for encoding the DVD? How about the BD, if the frame rates are OK?

I think we're getting close here!

poisondeathray

8th March 2016, 17:13

I'm not locked ino the 2 hour thing, if the file is too big for one disc at 25Mbps, I'll make it an hour and 45 minutes, or whatever it takes. Or if I add music and need trim the duration some, same plan.

This is where x264 will help you tremendously for AVC BD. On average, at typical BD bitrates and BD settings, you'd need 1.2-1.4x the size for similar quality using vegas' encoders

By using the "selecteven" command, Johns script outputs my file at 14.985. When I authored some straight (I didn't touch the files with any corrections or Avisynth scripts, just made copies for my sister till I could get her some "better" copies) DVD's earlier using Vegas, I disabled sampling and they outputed at the standard 29.97. Wouldn't that be one of the standard frame rates?

So HCEnc would be a prpper tool for encoding the DVD? How about the BD, if the frame rates are OK?

29.97 is good for NTSC DVD if it's really 30000/1001 (29.97 is an approximation), HCEnc will work fine for that

But 30000/1001 is not supported for progressive BD at HD resolutions. It must be encoded with fake interlace, or PAFF, or MBAFF (x264 can't do PAFF). So again, what you use to author will limit your choices

Bruce/Fl

8th March 2016, 23:51

29.97 is good for NTSC DVD if it's really 30000/1001 (29.97 is an approximation), HCEnc will work fine for that.

But 30000/1001 is not supported for progressive BD at HD resolutions. It must be encoded with fake interlace, or PAFF, or MBAFF (x264 can't do PAFF). So again, what you use to author will limit your choices

I've been using multiAVCHD some. Would that work? (a quick google using MBAFF, x264 and multiAVCHD as search terms shows what looks like success, albeit with some difficulty making menus, which I really don't care about.)

And if multiAVCHD isn't up to it, what is?

poisondeathray

9th March 2016, 01:25

Bruce/Fl

10th March 2016, 00:20

multiavchd should work for the authoring part. But it hasn't been updated in a long time. I'm not sure how it handles fake interlace x264 settings, but it should be able to author MBAFF

"fake interlace" is preferable from an encoding standpoint, because it's really encoded progressive (more efficient, higher quality), it's only signals "interlace" in the metadata to "trick" authoring tools and BD players. But MBAFF isn't that much worse, it still better than PAFF . But from a compatibilty perspective, some authoring tools have problems with "fake interlace", and some players might have problems with it as well. Native progressive would be ideal, but it's not supported at 30000/1001 for HD resolutions, only 24p is - that doesn't work for your cadenceAlright!

So, what are the next steps, and what programs will I need to proceed? Ideally guidance for both, using the sony 10bit result, and also the frameserver (in case the uncompressed are just too big to deal with effectively for me)

And try to spell things out with some details. What may be obvious to you is all new to me, never went down this road before.

Thank you

poisondeathray

10th March 2016, 06:44

Alright!

So, what are the next steps, and what programs will I need to proceed? Ideally guidance for both, using the sony 10bit result, and also the frameserver (in case the uncompressed are just too big to deal with effectively for me)

And try to spell things out with some details. What may be obvious to you is all new to me, never went down this road before.

It's quite a broad request, if you can be more specific/directed with your questions it would help.

Basically you apply the script as you have been doing. If you have sufficient HDD space, I would use temporary lossless intermediate. Because instead of having to apply the filters many times for multiple passes, or in addition to the frameserving overhead from vegas and DMFS, (typically you do 2 or more passes for BD or DVD) and for 2 versions (DVD and BD), you would only need to apply them once. It ends up being much faster, especially if you have slow scripts

The change to your current script is ConvertToYV12(matrix="Rec709"), and you don't need to convert back to RGB. You need to re-introduce duplicates after the denoising by adding ChangeFPS(30000,1001) to make it compatible with BD and DVD. Because I can't "see" what you're doing, and I might have missed something you've done differently - I would double check at this point that everything looks ok, including levels (e.g you can check with histogram() in avisynth, which is actually a Y waveform). For example, on a typical 8bit vegas project, when you frameserve from a studio RGB conversion, you actually need to use PC.709 (not Rec709) to essentially "reverse" the studio RGB conversion. So it's going to depend on how you have it set up. You should suspect this is the case if everything looks washed out, elevated black levels, low contrast. If everything looks fine, carry on

source=AVISource("C:\Users\Bruce\Desktop\fs.avi").selecteven().converttoYV12(matrix="rec709").killaudio
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
ChangeFPS(30000,1001)

For the BD, you need to use BD compatible settings. See the x264 BD reference links links below. They are just a starting point (you can feel free to tweak the settings, for exmaple you might not want to use "very slow" preset) . I think you were using 1920x1080 were you not? If not, you need to add borders . You would use the 1920x1080i settings (progressive content , encoded as MBAFF)
https://sites.google.com/site/x264bluray/home
http://forum.doom9.org/showthread.php?t=154533

For DVD, it needs to be resized to 720x480, and you need to change to SD colors with colormatrix, I can explain more later, but first do the output levels check

The 10bit workflow is more complex. You need to load with l-smash or ffms2 with the 10bit modification. I would try to use high bit depth filter equivalents of the script you're using now, for example there is a modified 16bit mdegrain2 (you're currently using the standard mdegrain2). You can experiment with that workflow once you get the standard 8bit workflow down, but the last step will always be dithering down to 8bit because 8bit is required for DVD and BD.

Bruce/Fl

10th March 2016, 16:15

It's quite a broad request, if you can be more specific/directed with your questions it would help.

What you wrote was good, gave me a strong idea about what is ahead.

But it did leave me with some follow on questions.

Basically you apply the script as you have been doing. If you have sufficient HDD space, I would use temporary lossless intermediate. Because instead of having to apply the filters many times for multiple passes, or in addition to the frameserving overhead from vegas and DMFS, (typically you do 2 or more passes for BD or DVD) and for 2 versions (DVD and BD), you would only need to apply them once. It ends up being much faster, especially if you have slow scripts

Could you elaborate on the bolded part?

I think I get the "2 versions(DVD and BD)" part, I'll have to take the part after Vegas, the script and authoring part, and run it twice, changing the "final size" and "in_bord (l&r)" lines to account for the differences between BD (1920x1080) and DVD (720x480), and the cropping required for the depan part. Possibly other parts as well, that I am unaware of.

The change to your current script is ConvertToYV12(matrix="Rec709"), and you don't need to convert back to RGB. You need to re-introduce duplicates after the denoising by adding ChangeFPS(30000,1001) to make it compatible with BD and DVD. Because I can't "see" what you're doing, and I might have missed something you've done differently - I would double check at this point that everything looks ok, including levels (e.g you can check with histogram() in avisynth, which is actually a Y waveform). For example, on a typical 8bit vegas project, when you frameserve from a studio RGB conversion, you actually need to use PC.709 (not Rec709) to essentially "reverse" the studio RGB conversion. So it's going to depend on how you have it set up. You should suspect this is the case if everything looks washed out, elevated black levels, low contrast. If everything looks fine, carry on

Again, please expand on the bolded part. Is it similar to the histogram in Vegas, and where would I see it?

source=AVISource("C:\Users\Bruce\Desktop\fs.avi").selecteven().converttoYV12(matrix="rec709").killaudio
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
ChangeFPS(30000,1001)

When I couldn't get Fred/Johns script loaded back into Vegas, I tried the degraining one I had success with before (which didn't work either, I had left out the convert to RGB line). That is the one (above) you showed how to fix for my present project. I'm actually working on a much bigger and complex script, which I linked at the bottom of post #3. You may be on top of that, but I just wanted to be clear in case it got confusing. I'm probably not the only person you're advising.

For the BD, you need to use BD compatible settings. See the x264 BD reference links links below. They are just a starting point (you can feel free to tweak the settings, for exmaple you might not want to use "very slow" preset) . I think you were using 1920x1080 were you not? If not, you need to add borders . You would use the 1920x1080i settings (progressive content , encoded as MBAFF)
https://sites.google.com/site/x264bluray/home
http://forum.doom9.org/showthread.php?t=154533

Thank you for the links. The x264 encoder, I haven't downloaded it yet, but does that do the same job that I was going to possibly use multiAVCHD for? EDIT, nevermind, I thought about that question and figured it out.

For DVD, it needs to be resized to 720x480, and you need to change to SD colors with colormatrix, I can explain more later, but first do the output levels check

Expand on the bolded part? And I apologize for being so, well, new.

The 10bit workflow is more complex. You need to load with l-smash or ffms2 with the 10bit modification. I would try to use high bit depth filter equivalents of the script you're using now, for example there is a modified 16bit mdegrain2 (you're currently using the standard mdegrain2). You can experiment with that workflow once you get the standard 8bit workflow down, but the last step will always be dithering down to 8bit because 8bit is required for DVD and BD.

Sounds like a plan.

I'll put the script I'm using (Video Freds modified by John Meyer) in the next post, (or two, if required). I'll post it as I got it from John in a PM and then bold the parts I replaced/changed/added, and then put in red what I changed it to, or simply added in some cases. (the change to RGB command, for example)

That way I won't post the same, long script twice, once original, and once tweaked for my use.

I see some things in it that I have questions about, things that seem odd to me, but I'm not one to critique, I'm probably just not understanding. I'll mention them in a post after I post the script. One is something I did, others I may have done accidently.

Bruce/Fl

10th March 2016, 16:17

# film restoration script by videoFred.
# denoising, resizing, stabilising, sharpening, auto-levels and auto-white balance.
#
# Modified by John Meyer, October 7, 2012
# Modified by John Meyer, July 7, 2015 (remove errors)
#
# Changes made by Meyer (June 8, 2010):
# 1. Replaced the MVDegrainMulti function, which was part of the original MVTools
# with the equivalent function using the newer and faster MVTools2.
# 2. Added RemoveDirt function prior to Degrain in order to eliminate large dust spots. This
# substantially improves the dirt removal capabilities of this script. The user will need to
# download this plugin at:
# http://www.removedirt.de.tf/
# 3. Eliminated a great deal of sharpening. The original script did sharpening in at least four places.
# With grainy film stock, this sometimes created objectionable grain. Also, the limitedSharpenFaster
# function, while excellent for video, is uncessarily slow, and isn't really needed for this low
# resolution source. Too much sharpening can make the film look too much like video.
# 4. Added multithreading. I was able to roughly triple the script performance. It may be possible to
# substantially increase this, perhaps as much as 12x instead of 3x. However, the autolevels function
# would have to be replaced.
# 5. Fixed several things I found. The result3 option didn't have the manual color correction code, so I
# added that back in. All the numbered "stab" variables (stab1, stab2, etc.) aren't needed except
# for providing a test function for stabilization. I eliminated all of this to streamline the script.
# 6. Deflicker seemed redundant, given all the averaging that takes place with MDegrain, and also the averaging
# that is done when the autolevels outputs are selected.
# 7. I reduced the number of frames used for averaging autolevels from the default (which is 5) to 2.
# I probably should add a variable in the header so the user can change this. Something else to do
# in the future ...
# 8. I added yet another set of crop parameters. I did this because both my capture and my output are
# done using NTSC DV AVI which is 720x480. However, 8mm film is almost exactly square, so the captured
# 720x480 video has black bars on the side. These need to be cropped off prior to doing motion
# stabilization, but then added back prior to the final output, which must still be 720x480 with the
# black bars on the side.
# 9. I reduced the default depan settings to 20, which is what was recommended in the original script. I
# also reduced the post-depan cropping. I did this so I could keep as much of the original frame
# as possible.
# 10. I removed the second denoising and sharpening function. It just seemed to be too much, and made the
# result too artificial
# 11. I removed the MVFLowFPS interpolation. I did this during one of dozens and dozens of attempts
# to improve the speed of the script. I should probably add this back, but if I do so, I also
# need to make it work correctly for interlaced output. If the goal is to show this on an NTSC or PAL
# television set, then it is not correct to convert from the film fps to 25 fps progressive (PAL) or
# 29.97 fps progressive (NTSC). Instead, this should be done as follows (example given is NTSC):
#
# MFlowFPS(source,super,backward_vec, forward_vec, num=60000, den=1001,ml=200)
# SeparateFields()
# SelectEvery(4, 0, 3)
# Weave()
#
# This yields interlaced 29.97, which has twice the temporal resolution as 29.97 progressive, and will
# therefore look correct on a TV set. I have done a lot of this as part of my Kinescope to video
# conversion scripts. For those scripts, the goal is to make the filmed version of a TV show look
# like it was actually videotaped. However, for something that originated on film, this "does violence"
# to the original feel of the media. It is true that it can make horizontal pans less "juddery," but
# it won't feel like film anymore. Also, this technique does break down, espcially with fast motion
# in the foreground.
# 12. Removed the unecessary "coloryuv(off_U=blue,off_V=red)" statement from the denoising section.
# 13. Added killaudio() statement to prevent lockups when using SetMTMode().
#
# Changes made on October 7, 2012
#
# 1. Modified RemoveDirtMC function to do estimation in two steps. This improves performance and quality.
# 2. Modified MDegrain to do estimation in two steps. This provides roughly the same quality with blocksize=8
# as what I was getting with blocksize=4, but with virtually no performance penalty
# 3. Updated to use special build of MVTools2 that works with SVP.
# 4. Moved Autolevels inside special multi-threading section in order to improve performance with autolevels.
# 5. Removed all trim commands because I do all editing outside the script (in Vegas).
# 6. Included two alternative ways to do frame interpolation: SVP and InterFrame. The InterFrame script is probably better
# but I included the SVP code because it may provide a starting point for more customized approaches. Neither is enabled by default.
#

#====================================================================================

Bruce/Fl

10th March 2016, 16:39

#VIDEO FILE
#----------------------------------------------------------------------------------------------------------------------------
#Change the following line to point to your video file
film="e:\fs.avi" #source=AVISource("C:\Users\Bruce\Desktop\fs.avi")

#GENERAL PARAMETERS
#----------------------------------------------------------------------------------------------------------------------------
result="resultS4" #specify the wanted output here
play_speed=16 #play speed (8mm=16; Super8=18; 16mm sound=24)

#COLOR AND LEVELS PARAMATERS
#----------------------------------------------------------------------------------------------------------------------------
saturation=1.0 #for all outputs
gamma=1.0 #for all outputs
blue= -0 red=-0 #manual color adjustment, when returning result3 & result4. Values can be positive or negative
black_level=0 white_level=255 output_black=0 output_white=255 #manual levels, when returning result2 & result4

#SIZE, CROP AND BORDERS PARAMETERS
#----------------------------------------------------------------------------------------------------------------------------
CLeft=8 CTop=8 CRight=8 CBottom=8 #crop values after Depan and before final resizing
W=720 H=480 #W=1920 H=1080 #final size after cropping
bord_left=0 bord_top=0 bord_right=0 bord_bot=0 #720p= borders 150
in_bord_left=0 in_bord_top=0 in_bord_right=0 in_bord_bot=0 #in_bord_left=240 in_bord_top=0 in_bord_right=240 in_bord_bot=0 #Borders around input that must be removed

#STABILISING PARAMETERS
#----------------------------------------------------------------------------------------------------------------------------
maxstabH=10 #maximum values for the stabiliser (in pixels) 20 is a good start value
maxstabV=10
est_left=40 est_top=40 est_right=40 est_bottom=40 #crop and contast values for special Estimate clip
est_cont=1.6

#DENOISING PARAMETERS
#----------------------------------------------------------------------------------------------------------------------------
#denoising_strength=600 #denoising level of first denoiser: MVDegrain()
denoising_strength=300 #denoising level of first denoiser: MVDegrain()
block_size= 16 #block size of MVDegrain
block_size_v= 16
block_over= 8 #block overlapping of MVDegrainMulti()

#denoising_strength= 600 #denoising level of first denoiser: MDegrain()
#block_size= 8 #block size of MVDegrain
#block_size_v= 8
#block_over= 4 #block overlapping of MVDegrainMulti()

#denoising_strength= 600 #denoising level of first denoiser: MDegrain()
#block_size= 4 #block size of MVDegrain
#block_size_v= 4
#block_over= 2 #block overlapping of MVDegrainMulti()

dirt_strength=18 #sets amount of dirt removal (big spots)

#FOUR STEP SHARPENING PARAMETERS
#--------------------------------------------------------------------------------------------------------------------------------
#PRE_sharp_ness= 120 PRE_radi_us= 3 #presharpening (UnsharpMask) just after first denoising
PRE_sharp_ness= 85 PRE_radi_us= 3 #presharpening (UnsharpMask) just after first denoising

LSF_sharp_ness=160 LSF_radi_us=2 LSF_sub=1.5 #second sharpening parameters (LimitedSharpenFaster) sub=subsampling

#Sharp_Strength = 0.4
Sharp_Strength = 0.1

#AUTO LEVELS PARAMETER
#--------------------------------------------------------------------------------------------------------------------------------
X=4 #X is a special parameter for reducing the autolevels effect on the whites
X2=4 #X2 is a special parameter for reducing the autolevels effect on the blacks

#NUMBER OF THREADS
#--------------------------------------------------------------------------------------------------------------------------------
threads=4

# END VARIABLES, BEGIN SCRIPT
#=================================================================================================================================

SetMemoryMax(768)

LoadPlugin ("mvtools2.dll") #Version 2.5.11.9 2/24/2012
LoadPlugin("autolevels.dll") #Version 0.6.0.0 1/09/2011
LoadPlugin("Deflicker.dll") #Version 0.4.0.0 8/16/2004
Loadplugin("Depan.dll") #Version 1.10.0.0 4/09/2007
LoadPlugin("DepanEstimate.dll") #Version 1.9.2.0 3/25/2007
LoadPlugin("fft3dfilter.dll") #Version 2.1.1.0 2/20/2007
Loadplugin("mt_masktools.dll") #Version 2.0.23.0 3/14/2008
loadplugin("RemoveDirtSSE2.dll") #Version 0.9 5/05/2005
Loadplugin("RemoveGrainSSE2.dll") #Version 0.9 5/01/2005
#Loadplugin("removegrain.dll") #Version 0.9 5/01/2005
Loadplugin("warpsharp.dll") # 4/05/2010

#Use the following for alternative frame interpolation
#loadplugin("svpflow1.dll") #Version 1.2.1.0 5/29/2012
#loadplugin("svpflow2.dll") #Version 1.3.1.0 6/02/2012
#Import("InterFrame2.avsi") #Version 2.1.0 6/27/2012

#Import("LimitedSharpenFaster.avs") #Not used in this script, but available if someone wants to experiment
#LoadPlugIn("LimitedSupport_09Jan06B.dll") #Used with LimitedSharpenFaster

#Remove all setmtmode statements (there are three in this script) if not using multi-threaded (MT) AVISynth
setmtmode(5,threads)
source1= Avisource(film).killaudio().assumefps(play_speed).converttoYV12() #source1=AVISource("C:\Users\Bruce\Desktop\fs.avi").selecteven().killaudio.ConverttoYv12()
cropped_source=source1.crop(in_bord_left,in_bord_top,-in_bord_right,-in_bord_bot) #remove any black borders on input video
setmtmode(2)

#cropped_source=filldrops(cropped_source) #Use this when removing bad frames that have been removed by duplicating previous frame

#STABILIZING
#....................................................................................................................................................................
stab_reference= cropped_source.crop(est_left,est_top,-est_right,-est_bottom).tweak(cont=est_cont).MT_binarize(threshold=80).greyscale().invert()
mdata=DePanEstimate(stab_reference,trust=1.0,dxmax=maxstabH,dymax=maxstabV)

#Deflicker may change colors !!
stab=DePanStabilize(cropped_source,data=mdata,cutoff=0.5,dxmax=maxstabH,dymax=maxstabV,method=1,mirror=15).deflicker()
#stab=DePanStabilize(cropped_source,data=mdata,cutoff=0.5,dxmax=maxstabH,dymax=maxstabV,method=1,mirror=15)

#DENOISING
#...................................................................................................................................................................
input_to_removedirt=stab.crop(CLeft,CTop,-CRight,-CBottom)
stabcrop=RemoveDirtMC(input_to_removedirt,dirt_strength,false)

prefiltered = RemoveGrain(stabcrop,2)
superfilt = MSuper(prefiltered, hpad=32, vpad=32,pel=2)
super= MSuper(stabcrop, hpad=32, vpad=32,pel=2)

halfblksize= (block_size>4) ? block_size/2 : 4
halfoverlap= (block_over>2) ? block_over/2 : 2

bvec1 = MAnalyse(superfilt, isb = true, delta = 1, blksize=block_size, overlap=block_over,dct=0)
bvec1 = MRecalculate(super, bvec1, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

fvec1 = MAnalyse(super, isb = false, delta = 1, blksize=block_size, overlap=block_over,dct=0)
fvec1 = MRecalculate(super, fvec1, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

bvec2 = MAnalyse(super, isb = true, delta = 2, blksize=block_size, overlap=block_over,dct=0)
bvec2 = MRecalculate(super, bvec2, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

fvec2 = MAnalyse(super, isb = false, delta = 2, blksize=block_size, overlap=block_over,dct=0)
fvec2 = MRecalculate(super, fvec2, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

# bvec3 = MAnalyse(super, isb = true, delta = 2, blksize=block_size, overlap=block_over,dct=0)
# bvec3 = MRecalculate(super, bvec3, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

# fvec3 = MAnalyse(super, isb = false, delta = 2, blksize=block_size, overlap=block_over,dct=0)
# fvec3 = MRecalculate(super, fvec3, blksize=halfblksize, overlap=halfoverlap,thSAD=100)

#super = stabcrop.MSuper(pel=2)
#bvec1 = MAnalyse(super, isb = true, delta = 1, blksize=block_size, overlap=block_over,dct=0)
#fvec1 = MAnalyse(super, isb = false, delta = 1, blksize=block_size, overlap=block_over,dct=0)
#bvec2 = MAnalyse(super, isb = true, delta = 2, blksize=block_size, overlap=block_over,dct=0)
#fvec2 = MAnalyse(super, isb = false, delta = 2, blksize=block_size, overlap=block_over,dct=0)
#bvec3 = MAnalyse(super, isb = true, delta = 3, blksize=block_size, overlap=block_over,dct=0)
#fvec3 = MAnalyse(super, isb = false, delta = 3, blksize=block_size, overlap=block_over,dct=0)

#Use the second line below, and un-comment two lines above if you want to average more frames. Doesn't seem necessary for most work IMHO.
denoised=stabcrop.MDegrain2(super, bvec1,fvec1,bvec2,fvec2,thSAD=denoising_strength).levels(0,gamma,255,0,255).tweak(sat=saturation).unsharpmask(PRE_sharp_ness,PRE_radi_us,0)
#denoised=stabcrop.MDegrain3(super, bvec1,fvec1,bvec2,fvec2,bvec3,fvec3,thSAD=denoising_strength).tweak(sat=saturation).unsharpmask(PRE_sharp_ness,PRE_radi_us,0)

#SHARPENING
#...................................................................................................................................................................
sharp1=denoised.sharpen(Sharp_Strength)
#sharp1=limitedSharpenFaster(denoised,smode=1,strength=LSF_sharp_ness,overshoot=50,radius=LSF_radi_us, ss_X=LSF_sub, SS_Y=LSF_sub, dest_x=W - bord_left - in_bord_left - bord_right - in_bord_right,dest_y=H - bord_top - in_bord_top - bord_bot - in_bord_bot)

PreBorderFrame = sharp1.Lanczos4Resize(W - bord_left - in_bord_left - bord_right - in_bord_right, H - bord_top - in_bord_top - bord_bot - in_bord_bot)

#FRAME INTERPOLATION (optional)
#...................................................................................................................................................................

/*
prefiltered = RemoveGrain(PreBorderFrame,2)
super = MSuper(PreBorderFrame,hpad=16, vpad=16, levels=1) # one level is enough for MRecalculate
superfilt = MSuper(prefiltered, hpad=16, vpad=16) # all levels for MAnalyse
backward = MAnalyse(superfilt, isb = true, blksize=16,overlap=8,search=3,dct=0)
forward = MAnalyse(superfilt, isb = false, blksize=16,overlap=8,search=3,dct=0)
forward_re = MRecalculate(super, forward, blksize=8, thSAD=100)
backward_re = MRecalculate(super, backward, blksize=8, thSAD=100)
PreBorderFrame = MFlowFps(PreBorderFrame,super, backward_re, forward_re, num=30000, den=1001,ml=200,mask=2)
*/

/*
superfps= MSuper(PreBorderFrame,pel=2)
backward_vec2 = MAnalyse(superfps, isb = true,blksize=16)
forward_vec2 = MAnalyse(superfps, isb = false,blksize=16)
PreBorderFrame = MFlowFps(PreBorderFrame,superfps, backward_vec2, forward_vec2, num=60000, den=1001, ml=200).SeparateFields().SelectEvery(4, 0, 3).Weave()
*/

#The following alternative can provide synthesized frames for hi-def material that causes MSuper to choke
#////// Begin alternative to MFlowFPS ////
#SmoothFPS2(PreBorderFrame,threads)
#////// End alternative to MFlowFPS ////

#The following is another alternative that can provide synthesized frames for hi-def material that causes MSuper to choke. Probably better than the one above.
#////// Begin alternative to MFlowFPS ////
#PreBorderFrame=InterFrame(NewNum=30000,NewDen=1001,PreBorderFrame,GPU=true,Cores=threads)
#////// End alternative to MFlowFPS ////

#Change SetMTMode for Autolevels

#SetMTMode(5,threads)

#RESULT1: AUTOLEVELS,AUTOWHITE
#......................................................................................................................................................................
result1= PreBorderFrame.coloryuv(autowhite=true).addborders(X,0,0,0,$FFFFFF).addborders(0,0,X2,0,$000000).autolevels(filterRadius=2).crop(X,0,-X2,-0).addborders(bord_left+in_bord_left, bord_top+in_bord_top, bord_right+in_bord_right, bord_bot+in_bord_bot)

#RESULT3: AUTOLEVELS, MANUAL COLOR CORRECTIONS
#.....................................................................................................................................................................
result3= PreBorderFrame.coloryuv(off_U=blue,off_V=red).addborders(X,0,0,0,$FFFFFF).addborders(0,0,X2,0,$000000).autolevels(filterRadius=2).crop(X,0,-X2,-0).addborders(bord_left+in_bord_left, bord_top+in_bord_top, bord_right+in_bord_right, bord_bot+in_bord_bot)

#SetMTMode(2)

#RESULT2: MANUAL LEVELS, AUTOWHITE
#......................................................................................................................................................................
result2= PreBorderFrame.levels(black_level,gamma,white_level,0,255).coloryuv(autowhite=true).addborders(bord_left+in_bord_left, bord_top+in_bord_top, bord_right+in_bord_right, bord_bot+in_bord_bot)

#RESULT4: MANUAL LEVELS, MANUAL COLOR CORRECTIONS
#.....................................................................................................................................................................
result4= PreBorderFrame.coloryuv(off_U=blue,off_V=red).levels(black_level,gamma,white_level,0,255).addborders(bord_left+in_bord_left, bord_top+in_bord_top, bord_right+in_bord_right, bord_bot+in_bord_bot)

#PARAMETERS FOR THE COMPARISONS
#.....................................................................................................................................................................
W2= W+bord_left+bord_right
H2= H+bord_top+bord_bot
source4=Lanczos4Resize(source1,W2,H2)

#COMPARISONS: ORIGINAL VS RESULTS
#......................................................................................................................................................................
resultS1= stackhorizontal(subtitle(source4,"original",size=28,align=2),subtitle(result1,"autolevels, autowhite",size=28,align=2))
resultS2= stackhorizontal(subtitle(source4,"original",size=28,align=2),subtitle(result2,"autowhite, manual levels correction",size=28,align=2))
resultS3= stackhorizontal(subtitle(source4,"original",size=28,align=2),subtitle(result3,"autolevels, manual color correction",size=28,align=2))
resultS4= stackhorizontal(subtitle(source4,"original",size=28,align=2),subtitle(result4,"manual colors and levels correction",size=28,align=2))

Eval(result)
ConvertToRGB24()

# END SCRIPT, BEGIN FUNCTIONS
#=================================================================================================================================

Bruce/Fl

10th March 2016, 16:40

And the last of the script.

#REMOVE DIRT FUNCTION
#......................................................................................................................................................................
function RemoveDirt(clip input, int "limit", bool "_grey")
{
clensed=input.Clense(grey=_grey, cache=4)
alt=input.RemoveGrain(2)
return RestoreMotionBlocks(clensed,input,alternative=alt,pthreshold=6,cthreshold=8, gmthreshold=40,dist=3,dmode=2,debug=false,noise=limit,noisy=4, grey=_grey)

# Alternative settings
# return RestoreMotionBlocks(clensed,input,alternative=alt,pthreshold=4,cthreshold=6, gmthreshold=40,dist=1,dmode=2,debug=false,noise=limit,noisy=12,grey=_grey,show=true)
# return RestoreMotionBlocks(clensed,input,alternative=alt,pthreshold=6,cthreshold=8, gmthreshold=40,dist=3,tolerance= 12,dmode=2,debug=false,noise=limit,noisy=12,grey=_grey,show=false)
}

function RemoveDirtMC(clip,int "limit", bool "_grey")
{
_grey=default(_grey, false)
limit = default(limit,6)

# prefiltered = fft3dfilter(clip,sigma=1,sigma2=2,sigma3=3,sigma4=5,bw=64,bh=64)

prefiltered = RemoveGrain(clip,2)
superfilt = MSuper(prefiltered, hpad=32, vpad=32,pel=2)

super=MSuper(clip, hpad=32, vpad=32,pel=2)

bvec = MAnalyse(superfilt,isb=true, blksize=16, overlap=2,delta=1, truemotion=true)
fvec = MAnalyse(superfilt,isb=false, blksize=16, overlap=2,delta=1, truemotion=true)

# Increase thSAD if moving objects are being removed!!
bvec_re = Mrecalculate(super,bvec,blksize=8, overlap=0,thSAD=100)
fvec_re = Mrecalculate(super,fvec,blksize=8, overlap=0,thSAD=100)

backw = MFlow(clip,super,bvec_re)
forw = MFlow(clip,super,fvec_re)

clp=interleave(forw,clip,backw)
clp=clp.RemoveDirt(limit,_grey)

# Alternative to RemoveDirt call above
# clp = clp.DeSpot(p1=20, p2=4, pwidth=30, pheight=30, mthres=22, merode=33, sign=1, seg=0, color=false, \
# motpn=false, fitluma=true, mark_v=255)

# clp = clp.invert.DeSpot(p1=12, p2=6, pwidth=18, pheight=16, mthres=22, merode=25, p1percent=10, sign=1, show=Show, seg=1, \
# color=true, motpn=false, mark_v=255).invert

clp=clp.SelectEvery(3,1)
return clp
}

#This function is the previous way to do motion estimation. It is slower and not as accurate.
function RemoveDirtMC_old(clip,int limit, bool "_grey")
{
_grey=default(_grey, false)
limit = default(limit,6)
i=MSuper(clip,pel=2)
fvec = MAnalyse(i,isb=false, blksize=16, delta=1, truemotion=true)
bvec = MAnalyse(i,isb=true, blksize=16, delta=1, truemotion=true)
backw = MFlow(clip,i,bvec)
forw = MFlow(clip,i,fvec)
clp=interleave(forw,clip,backw)
clp=clp.RemoveDirt(limit,_grey)
clp=clp.SelectEvery(3,1)
return clp
}

# This function will remove near duplicates ("0.1") or exact duplicates (change to "0.0"). It replaces these
# duplicates with a motion estimated frame.
# Use: In your video editor, replace any single bad frame (burned frame, jump, missing frame from splice, etc.) with a duplicate of the
# previous frame. Then, include a call to this function
function filldrops (clip c)
{
super=MSuper(c,pel=2)
vfe=manalyse(super,truemotion=true,isb=false,delta=1)
vbe=manalyse(super,truemotion=true,isb=true,delta=1)
filldrops = mflowinter(c,super,vbe,vfe,time=50)
fixed = ConditionalFilter(c, filldrops, c, "YDifferenceFromPrevious()", "lessthan", "0.1")
return fixed
}

function SmoothFPS2(clip source, threads) {
super_params="{pel:2,gpu:1}"
analyse_params="""{
block:{w:16,h:16},
main:{search:{coarse:{distance:-10}}},
refine:[{thsad:200}]
}"""
smoothfps_params="{rate:{num:30,den:16,abs:false},scene:{mode:0,limits:{scene:8500}},algo:21,cubic:1}"
threads = 4

super = SVSuper(source,super_params)
vectors = SVAnalyse(super, analyse_params)
SVSmoothFps(source,super, vectors, smoothfps_params, url="www.svp-team.com", mt=threads)

# Alternative for interlaced output
# SVSmoothFps(source,super, vectors, smoothfps_params, url="www.svp-team.com", mt=threads).SeparateFields().SelectEvery(4, 0, 3).Weave().assumefps(29.97)
}

Bruce/Fl

10th March 2016, 16:58

Now, I mentioned some things that looked odd to me in the script.

But like I mentioned, the script works as I have it. I mean, it doesn't hang up, and I see improvements. Maybe I'm not seeing all of the improvements, but it looks much better to my eyes.

What comes to mind are the following. (There may be more that I can't remember right now)

1. In the area where the "loadplugins" are listed, The removegrain.dll is #'d out. As far as I can see, it is used, and shouldn't be #'d out. Am I missing something, or is it something like it is in my plugins folder so the script found it without the callout? (I checked, the SSE2 version wasn't used in it's place, ....... as far as I can tell)

2. On the line where Source1 is assigned, I didn't know what to put in for the assumefps, (16 or 15, I thought 15 might be in play...) so I left it blank, thinking a box might pop up and tell me what was wrong (and that I could then figure out what the right choice was). But it went through, so I didn't fix what wasn't broke. Probably a mistake on my part.

But it seems to work. Is that something I need to fix?

3. I wasn't really sure where to put the ConvertToRGB24(), on my second guess, it took, and it worked.

But I understand I won't need that anymore with the new course of action.

4. I tried using MT, not sure if it worked or not, heh. (I erroneously was using the Vegas render as the time I measured to gauge its effectiveness, oops!) But in the script, there is a comment that if you want to use MT, to uncomment the setMT commands and make them active. It says there are 3 of them, but I think I counted four. Did I not see something that would have disallowed one of them?

I'm probably forgetting one or more, but that's all that comes to mind at the moment.

poisondeathray

10th March 2016, 17:54

For DVD, it needs to be resized to 720x480, and you need to change to SD colors with colormatrix, I can explain more later, but first do the output levels check

Could you elaborate on the bolded part?

I think I get the "2 versions(DVD and BD)" part, I'll have to take the part after Vegas, the script and authoring part, and run it twice, changing the "final size" and "in_bord (l&r)" lines to account for the differences between BD (1920x1080) and DVD (720x480), and the cropping required for the depan part. Possibly other parts as well, that I am unaware of.

2 or more passes for encoding - it's required for accuracy in bitrate convergence . When using DVD/BD, you have fixed media, fixed capacity limitations. You need to be accurate in your bitrate , and want to err on the side of undersizing, because if you oversize you have to redo the encode (it won't fit the media) . You need to use an appropriate bitrate calculator to determine what bitrate to use. 1 pass encodes usually overshoot or undershoot. 2 or more passes not only improve the quality and bitrate allocation, it will come closer to the desired target bitrate

When using slow filters (anything: vdub, vegas, avisynth) , and frameserving overhead of vegas (or premiere or any frameserver) - you don't want to incur that speed penalty numerous times. You only want to incur that penalty once. That is what a lossless intermediate is commonly used for - your filters and edits etc.. are already applied to the intermediate so you don't have to undergo the slow bottlenecks multiple times (each pass). You use the highest resolution version for the intermediate, because you can always go down, but upsizing will result in quality loss

Again, please expand on the bolded part. Is it similar to the histogram in Vegas, and where would I see it?

Similar, but it's more like the waveform in vegas, not the RGB histogram. You would preview your scripts. Common methods are vdub, or avspmod (push f5) . Avspmod is the closest thing to an "editor" for avisynth. You can compare script versions in multiple tabs (number keys to switch)

http://avisynth.nl/index.php/Histogram
See the pictures. It's actually rotated 90 degrees to the right, basically you want your values to be mostly in between the brown bars (brown bars are "illegal", 0-15, 236-255) . You can use the TurnRight.Histogram.TurnLeft manipulation suggested to turn it right side up, the way it looks in most programs

Thank you for the links. The x264 encoder, I haven't downloaded it yet, but does that do the same job that I was going to possibly use multiAVCHD for? EDIT, nevermind, I thought about that question and figured it out.

multiavchd can encode non compliant assets, and author. I wouldn't use it to encode these days, because it hasn't been updated in many years. It doesn't have switches like --bluray-compat for example, or any of the improvements made in the last few years. The binary it uses predates those changes , and you cannot drop in a binary to replace x264.exe, unless it's from the same core revision. So I would only use it for authoring purposes

Quote:
For DVD, it needs to be resized to 720x480, and you need to change to SD colors with colormatrix, I can explain more later, but first do the output levels check
Expand on the bolded part? And I apologize for being so, well, new.

Expand on the bolded part? And I apologize for being so, well, new.

By convention, SD uses Rec601, HD uses Rec709 . Those are the matrices that govern YUV <=>RGB conversions. If you use the wrong one, the colors will be slightly shifted and look a bit "off" because the hardware will be using the expected conversion. Colormatrix() changes in colors in YUV, as if you had used another matrix when converting from RGB. This is preferred to actually converting back to RGB and then back to YUV again (because addional avoidable lossess there) . Since for your HD version you used 709, you would need to add Colormatrix(mode="rec.709->rec.601", clamp=0) . You could just as easily used ConvertToYV12(matrix="rec601") from the RGB version for the SD version, but you don't want to have to undergo multiple slow filters (again, the lossless intermediate discussion above)

poisondeathray

10th March 2016, 17:57

Now, I mentioned some things that looked odd to me in the script.

But like I mentioned, the script works as I have it. I mean, it doesn't hang up, and I see improvements. Maybe I'm not seeing all of the improvements, but it looks much better to my eyes.

Possibly you're using the frameserved duplicates version as input ; recall in the other script the selecteven() ?

1. In the area where the "loadplugins" are listed, The removegrain.dll is #'d out. As far as I can see, it is used, and shouldn't be #'d out. Am I missing something, or is it something like it is in my plugins folder so the script found it without the callout? (I checked, the SSE2 version wasn't used in it's place, ....... as far as I can tell)

If you're missing a plugin required for that script, you'll get an error message. So don't worry about it.

2. On the line where Source1 is assigned, I didn't know what to put in for the assumefps, (16 or 15, I thought 15 might be in play...) so I left it blank, thinking a box might pop up and tell me what was wrong (and that I could then figure out what the right choice was). But it went through, so I didn't fix what wasn't broke. Probably a mistake on my part.

But it seems to work. Is that something I need to fix?

You need to check the frameserved rate from vegas with info()

AVISource("C:\Users\Bruce\Desktop\fs.avi")
Info()

I suspect it's 29.97 or 30000/1001 ,if you've sent the duplicates version from vegas. You can use AssumeFPS(30000,1001) to get it perfect at that point. Recally, to get effective filtering you need to remove dupliates before you apply the filters (you need unique frames). That was what the SelectEven() was for in your earlier script. That will remove every odd frame and your effective frame rate will alos be cut in half.

So at the end of the filtering script, you would use ChangeFPS(30000,1001) to re-introduce the duplicates (for NTSC DVD and BD compatiblity purposes)

3. I wasn't really sure where to put the ConvertToRGB24(), on my second guess, it took, and it worked.

But I understand I won't need that anymore with the new course of action.

You don't need converttorgb24() anywmore - the main point of this was to avoid that since you're not going back to vegas, and not using deshaker or anything

4. I tried using MT, not sure if it worked or not, heh. (I erroneously was using the Vegas render as the time I measured to gauge its effectiveness, oops!) But in the script, there is a comment that if you want to use MT, to uncomment the setMT commands and make them active. It says there are 3 of them, but I think I counted four. Did I not see something that would have disallowed one of them?

It looks like four. Test speed with avsmeter. Report back if you're not seeing differences in speed

Bruce/Fl

10th March 2016, 18:10

One question I forgot to ask.

Say I do my Vegas work, render out with the lossless codec. How do I get the file into Avisynth? VDub? Before in my Vegas - Avisynth - Vegas flow, I used DBFS and AVFS. I think i understand that I can still use DBFS, but that has the down side of knocking it down to 8bit way early in the process. What are the other options that wouldn't do that?

poisondeathray

10th March 2016, 18:16

Say I do my Vegas work, render out with the lossless codec. How do I get the file into Avisynth? VDub? Before in my Vegas - Avisynth - Vegas flow, I used DBFS and AVFS. I think i understand that I can still use DBFS, but that has the down side of knocking it down to 8bit way early in the process. What are the other options that wouldn't do that?

An 8bit RGB lossless codec like lagarith, ut etc... when used in RGB mode would be identical to using DMFS in RGB mode

The other option is to use the 10bit RGB (r10k or r210), or 10bit 422 YUV (v210) as mentioned earlier

v210 would be loaded into avisynth with l-smash, or the ffms2 10bit modified version. You would try to replace some or all of your filters with stack16 versions, but I don't know if they are equivalents for your current script - for example I don't think there is a depan stack16 version

poisondeathray

10th March 2016, 18:47

A workflow point that I'm not sure you're aware of (it might be "too late" for you now, depending on what manipulations you did in vegas, but to keep in mind for the future). If you've made edits in vegas (cuts etc..), make sure you cut after the duplicate frame, otherwise you will get cadence problems. It's the same idea when editing footage with various pulldown patterns without the pulldown removed - there are special frames that you are only allowed to cut on. Duplicates are effectively a 2:2 pulldown pattern

Assuming the assets you got from cinepost were indeed 29.97 with duplicates (double check that vegas "sees" and interprets the framerate as 29.97, otherwise you will get unexpected results), I would have set the vegas project to "half NTSC 14.985", or half framerate to decimate the duplicates. You would then have a perfect 1:1 version within vegas. You wouldn't have to pay attention to where you cut. You wouldn't have additional frames to serve or excess overhead (1/2 the number of frames to serve will be much faster, even if you decimate in avisynth) , and lossless exports would be 1/2 the size.

Bruce/Fl

11th March 2016, 00:05

An 8bit RGB lossless codec like lagarith, ut etc... when used in RGB mode would be identical to using DMFS in RGB mode

The other option is to use the 10bit RGB (r10k or r210), or 10bit 422 YUV (v210) as mentioned earlier

WhenIsaid lossless, I was referrin to the 10bit 422 YUV (v210) one. I should have been more specific, because the others could have been lossless as well, just cdropping the chroma.

v210 would be loaded into avisynth with l-smash, or the ffms2 10bit modified version. You would try to replace some or all of your filters with stack16 versions, but I don't know if they are equivalents for your current script - for example I don't think there is a depan stack16 version

"l-smash, or the ffms2 10bit modified version", I have neither programs as of yet, is one or the other more suited (or maybe more intuitive) for my needs?

What happens if I can't get all of the filters in 10 bit versions? Does even having one in 8 bit drag down the project into 8 bit? Sort of the "weakest link" syndrome?

A workflow point that I'm not sure you're aware of (it might be "too late" for you now, depending on what manipulations you did in vegas, but to keep in mind for the future). If you've made edits in vegas (cuts etc..), make sure you cut after the duplicate frame, otherwise you will get cadence problems. It's the same idea when editing footage with various pulldown patterns without the pulldown removed - there are special frames that you are only allowed to cut on. Duplicates are effectively a 2:2 pulldown pattern

I'm pretty sure I made the right cuts, everytime I made one, I could "see" the frames on each side of the cut, they were always different. But I'll redo those two reels, as I like what your next paragraph said.

Assuming the assets you got from cinepost were indeed 29.97 with duplicates (double check that vegas "sees" and interprets the framerate as 29.97, otherwise you will get unexpected results), I would have set the vegas project to "half NTSC 14.985", or half framerate to decimate the duplicates. You would then have a perfect 1:1 version within vegas. You wouldn't have to pay attention to where you cut. You wouldn't have additional frames to serve or excess overhead (1/2 the number of frames to serve will be much faster, even if you decimate in avisynth) , and lossless exports would be 1/2 the size.

Yes, I wasn't aware of that capability (but then again, I only know about 1% of what Vegas can do, it does so much), and it's easy to see where that would trim the size in half. "Too late"?, well, yes, but just a bit, and I can redo the work that I already did. I had two reels spliced at scene changes, ready for color/brightness corrections, but that was all.

I found the "half NTSC 14.985" option in the "project properties" area, and gave it a trial. Looks like it does exactly that, took out every other frame. No more dupes.

Is there some option I should be aware of as I render out to ensure it stays in that mode? I have been selecting "disable resample", but that was in my second, final run through Vegas, getting ready for the rendering. This is a different course of action. (and I also assume I need to get rid of the "selecteven()" line in the script, if 1/2 are already removed going in)

While I was in project properties I noticed it was not set to progressive, it should be, correct? Are there any other selections I should ensure are in a "non default" way? I usually just go with default unless I have been shown to do otherwise.

poisondeathray

11th March 2016, 00:45

"l-smash, or the ffms2 10bit modified version", I have neither programs as of yet, is one or the other more suited (or maybe more intuitive) for my needs?

l-smash is better these days IMO. ffms2 is a bit more inconsistent

What happens if I can't get all of the filters in 10 bit versions? Does even having one in 8 bit drag down the project into 8 bit? Sort of the "weakest link" syndrome?

Yes

Yes, I wasn't aware of that capability (but then again, I only know about 1% of what Vegas can do, it does so much), and it's easy to see where that would trim the size in half. "Too late"?, well, yes, but just a bit, and I can redo the work that I already did. I had two reels spliced at scene changes, ready for color/brightness corrections, but that was all.

I found the "half NTSC 14.985" option in the "project properties" area, and gave it a trial. Looks like it does exactly that, took out every other frame. No more dupes.

If you're certain the cuts you made were consistent , there might be a way you can salvage that by "nesting veggies" . Basically you import the old project file (pretend it's a "video"), into a new project with the new settings.

Is there some option I should be aware of as I render out to ensure it stays in that mode? I have been selecting "disable resample", but that was in my second, final run through Vegas, getting ready for the rendering. This is a different course of action. (and I also assume I need to get rid of the "selecteven()" line in the script, if 1/2 are already removed going in)

It won't hurt to disable resample (unless you've done other manipulations like speed changes) . Resampling occurs , only when there is a mistmatch in frame rates for either the file interpretation rate (what vegas "thinks" the source file is), the project frame rate, or the export settings frame rate. If all 3 match, no resampling is occurring. When resampling occurs, the default mode is "blend" , so it will add blended frames if you have a higher destination frame rate than the source frame rate. This shouldn't affect you because you have perfect decimation ratio 29.97 /2 = 14.985 . So the decimation is perfect. This is why I mentioned you should make sure to check the file interpretation frame rate (what vegas "thinks" the frame rate is of the source files). If the header of the source files was slightly off, vegas might "think" the rate is slightly different and you won't get perfect 1:1 results, you will get some dropped frames or duplicate frames in places. For example if the source rate was 30.0, you should be using 15.0

Yes, if you're frameserving or exporting out a 1:1 unique frames version, you don't need the selecteven(). That was only to get rid of the duplicates

While I was in project properties I noticed it was not set to progressive, it should be, correct? Are there any other selections I should ensure are in a "non default" way? I usually just go with default unless I have been shown to do otherwise.

Yes, progressive should be set in the properties, and when exporting make sure all the settings match too , in terms of dimensions, FPS, progressive etc...

Bruce/Fl

11th March 2016, 03:48

l-smash is better these days IMO. ffms2 is a bit more inconsistent

OK, I was misinterpreting the use for lsmash I think.

I was asking about the program that I should be using to host the script. (Like where I would load up the location of the script after "start avfs "c:\users\bruce\....." " which points the way to the script, not the video file.

I will be using lsmash to load the video file needed for the script to do its thing, as in "LSMASHVideoSource("xxxxx.mov") instead of "source=AVISource("C:\Users\....", correct? But that is for the media file itself, not hosting the script.

What program will be hosting the script? (If I am understanding what is going on correctly, which is by no means a given)

Bruce/Fl

11th March 2016, 04:02

You need to check the frameserved rate from vegas with info()

AVISource("C:\Users\Bruce\Desktop\fs.avi")
Info()

I'm probably being dense here, but bear with me.

I added the "Info()" line to the script, and it crashed it. The error log said "Invalid arguments to function "Info" "

What did I do wrong. (and to be honest, I had no idea where the "info" would be displayed.)

poisondeathray

11th March 2016, 04:17

OK, I was misinterpreting the use for lsmash I think.

I was asking about the program that I should be using to host the script. (Like where I would load up the location of the script after "start avfs "c:\users\bruce\....." " which points the way to the script, not the video file.

I will be using lsmash to load the video file needed for the script to do its thing, as in "LSMASHVideoSource("xxxxx.mov") instead of "source=AVISource("C:\Users\....", correct? But that is for the media file itself, not hosting the script.

What program will be hosting the script? (If I am understanding what is going on correctly, which is by no means a given)

There is no real "host", or at least not in the way you're probably thinking . The script is fed directly to the encoder (x264 for AVC for BD , HCEnc for MPEG2 for DVD - both accept avs scripts natively)

You can use a program like avspmod or vdub to preview the scripts. I recommend avspmod. It will allow you to tweak your scripts more easily. Lets say you're wondering what values to use for the script for denoising strength. Well you can compare different versions of the script in multiple tabs (it's like tabs in a browser) and swap between them with the number keys

I'm probably being dense here, but bear with me.

I added the "Info()" line to the script, and it crashed it. The error log said "Invalid arguments to function "Info" "

What did I do wrong. (and to be honest, I had no idea where the "info" would be displayed.)

Just preview the script in vdub or avspmod . There will be an overlay in the upper left hand corner with yellow text

Bruce/Fl

11th March 2016, 09:43

There is no real "host", or at least not in the way you're probably thinking . The script is fed directly to the encoder (x264 for AVC for BD , HCEnc for MPEG2 for DVD - both accept avs scripts natively)

You can use a program like avspmod or vdub to preview the scripts. I recommend avspmod. It will allow you to tweak your scripts more easily. Lets say you're wondering what values to use for the script for denoising strength. Well you can compare different versions of the script in multiple tabs (it's like tabs in a browser) and swap between them with the number keys

avspmod won't open for me. I read the notes, the way I read it I don't need that python program, as I'm in windows.

I get the error message:

Traceback (most recent call last):
File "run.py", line 38, in <module>
ImportError: No module named os

I see the .py, but wonder why ....

Just preview the script in vdub or avspmod . There will be an overlay in the upper left hand corner with yellow text

I tried in VD, because I know that works.

Nothing runs witht he added "Info()"

Without it, it runs, but there is no added text.

I can get some ifo by selecting "show status window"

poisondeathray

11th March 2016, 16:02

I tried in VD, because I know that works.

Nothing runs witht he added "Info()"

Without it, it runs, but there is no added text.

I can get some ifo by selecting "show status window"

It's not that important for what you are doing, but it raises other questions about your avisynth install/system since it's one of the most basic commands. It suggests there might be other problems.

With the script loaded in vdub, you can get similar info in vdub with file=>file information

Can you create another script, preview that in vdub ?

blankclip()
info()

Bruce/Fl

11th March 2016, 17:45

It's not that important for what you are doing, but it raises other questions about your avisynth install/system since it's one of the most basic commands. It suggests there might be other problems.

With the script loaded in vdub, you can get similar info in vdub with file=>file information

Can you create another script, preview that in vdub ?

blankclip()
info()

That worked for me, I got 14 lines of info, yellow text on a black background.

Here is what I was trying, I tried both the big script, and also the short degrain script.

Did I leave too much in?

source=AVISource("C:\Users\Bruce\Desktop\fs.avi").selecteven().killaudio
Info()
super = MSuper(source,pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, overlap=4)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, overlap=4)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, overlap=4)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, overlap=4)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)
return final
#stackhorizontal (source,final)

EDIT: I think i have this now, I thought maybe it was too much, so I tried:

source=AVISource("C:\Users\Bruce\Desktop\fs.avi").selecteven().killaudio
Info()

Which still didn't work.

Then I looked at your suggestion a few posts ago, and saw that there was no "source="

So I took that out, along with the ".selecteven().killaudio" and tried it again:

AVISource("C:\Users\Bruce\Desktop\fs.avi")
Info()

That worked.

(I thought you gave me the lead in line to show me where to put the "Info()". I didn't realize till just now that that was the *only* text I was supposed to run in the script.)

Did you want some particular info it gave besides this? It showed "Frames per second: 29.9700 (2997/100)"

And that was from the way I was doing it before, not taking out 1/2 the frames in Vegas.

Bruce/Fl

11th March 2016, 22:21

avspmod won't open for me. I read the notes, the way I read it I don't need that python program, as I'm in windows.

I get the error message:

Traceback (most recent call last):
File "run.py", line 38, in <module>
ImportError: No module named os

I see the .py, but wonder why ....

And any idea what's going on here? I double click the executable, but nothing happens.

The "what do you want to do" box pops up, I hit "run", and, ........... nothing.

Do I need to open it once the script is running or something like that? (Like in x264, or HCEnc? Both of which I have no knowledge of yet)

poisondeathray

11th March 2016, 22:39

No idea about the avspmod error. I would ask in the avspmod thread. Just a wild guess but are you logged in as administrator? and have all permisions like write to that directory ? It stores last session info in the folder

You don't need it open when encoding . It's only to preview and edit scripts. You're not frameserving from avspmod (it's not like vegas and dmfs, where vegas needs to be open actively frameserving)

johnmeyer

11th March 2016, 22:44

MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=1400)
final=assumefps(15/1.001)That is a really large thSAD value.

I recommend using decimal points for the assumefps call or you will end up with the wrong speed:

assumefps(15.0/1.001)

StainlessS

11th March 2016, 22:58

I recommend using alternative int numerator, denominator call

eg Assumefps(15000,1001 [,sync_audio=true]) # Optional [EDIT: oops, changed 1500 to 15000]

From docs
AssumeFPS (clip, int numerator [, int denominator], bool "sync_audio")

EDIT: 15/1.001, the 15 is converted to float before division (because the 1.001 is float, but the alternate int call is more accurate).

EDIT: More from docs

In v2.57, the behaviour with respect to the framerate is a bit changed. The main issue is that users are allowed to specify the framerate as float, but the NTSC (FILM and Video) and PAL standards require ratios as framerate. Besides this AviSynth exports the framerate as a ratio, so when specifying a float, it will be converted to a ratio. The ratios of the standards are given by 24000/1001 for 23.976 (FILM) and 30000/1001 for 29.97 (Video). When specifying these floats, they are exported by AviSynth as ratios, but not as the standard ratios. One of the reasons for this is, that those floats are approximations (remember that 24000/1001 = 23.9760239760...), so how should AviSynth know how to choose the correct ratio? In order to overcome this issue, the user can use AssumeFPS(24000,1001) or simply AssumeFPS("ntsc_film").

Bruce/Fl

12th March 2016, 00:51

Bruce/Fl

12th March 2016, 00:59

I recommend using alternative int numerator, denominator call

eg Assumefps(1500,1001 [,sync_audio=true]) # Optional

From docs

EDIT: 15/1.001, the 15 is converted to float before division (because the 1.001 is float, but the alternate int call is more accurate).

EDIT: More from docs

In v2.57, the behaviour with respect to the framerate is a bit changed. The main issue is that users are allowed to specify the framerate as float, but the NTSC (FILM and Video) and PAL standards require ratios as framerate. Besides this AviSynth exports the framerate as a ratio, so when specifying a float, it will be converted to a ratio. The ratios of the standards are given by 24000/1001 for 23.976 (FILM) and 30000/1001 for 29.97 (Video). When specifying these floats, they are exported by AviSynth as ratios, but not as the standard ratios. One of the reasons for this is, that those floats are approximations (remember that 24000/1001 = 23.9760239760...), so how should AviSynth know how to choose the correct ratio? In order to overcome this issue, the user can use AssumeFPS(24000,1001) or simply AssumeFPS("ntsc_film").

So the correct way (ways?) to enter the speed is?

It looks like to me, if I read it correctly, is that 30,000/1001 and possibly, and I'm projecting here, "AssumeFPS("ntsc_video")"?

(If 24=film, then 30=video?)

StainlessS

12th March 2016, 01:35

Looks ok to me, ie 30000,1001 for 29.97 and 24000,1001 for 23.976.

More here:- http://avisynth.nl/index.php/FPS

EDIT: clarification,

Assumefps(30000,1001)
# And
Assumefps(24000,1001)
# And
Assumefps(15000,1001)

Bruce/Fl

19th March 2016, 09:50

The problem is cineform currently isn't handled at 10bit with avisynth properly. To do anything at >8 bit in avisynth, you need to used the "stacked" 16bit workflow. There are ways to load 10bit as stacked 16 into avisynth with l-smash and ffms2 (10bit hack version) , but not for cineform yet.

Now that I have the script issues mostly worked out, I thought I'd take a stab at feeding the Avisynth script something more robust than the type of avi that DMFS generates, that i've been able to use "source=AVISource("C:\Users,,,,,")".

I downloaded the LSmash files earlier, and was hoping to give them a try. If it becomes too much of an ordeal, I'll probably just defer to using DMFS, but I am hopeful that I won't have to do that.

So I went to where the video gets selected in the script and tried: "source=LSMASHVideoSource("G:\Home Movies......avi" (output after rendering with the sony 10bit YUV AV codec) and that obviously didn't work. I dug some, and according to the avisynth wiki (http://avisynth.nl/index.php/LSMASHSource/LSMASHVideoSource) it should look something kike this maybe?

"LSMASHVideoSource(source="source.mp4", track=0, threads=0, seek_mode=0,
\ seek_threshold=10, dr=false, fpsnum=0, fpsden=1, stacked=false, format="")"

But I believe it was said that I would need to have a "stacked" input, I see where after the source line, there are numerous options (track, threads, etc) and one of them is "stacked=false".

It looks like my situation will be a variation of that example.

Am I on the right track?

And if so, can you clear up the source loading line of text any?

Thank you

poisondeathray

20th March 2016, 04:59

Bruce/Fl

20th March 2016, 07:30

If you have 10bit source, eg. v210
LSmashVideoSource("INPUT.mov", format="YUV422P16", stacked=true)

But you're probably using v210 AVI as Sony YUV 10bit, so use
LWLibavVideoSource("INPUT.avi", format="YUV422P16", stacked=true)

Thank you, and yes, I am using the Sony YUV 10bit.

So I plugged that source statement in. In the script there are two places where there is a "source" line. The first one is up around line 79, right underneath all the notes, and under "VIDEO FILE", (source=)

This is what I put there:

source=LWLibavVideoSource("C:\Users\Bruce\Desktop\fs.avi", format="YUV422P16", stacked=true)

And the second one is a few lines under where all the loadplugin statements were, (source1=)

This is what I put there:

source1=LWLibavVideoSource("C:\Users\Bruce\Desktop\fs.avi", format="YUV422P16", stacked=true).assumefps(15000,1001).ConverttoYv12(matrix="rec709").killaudio

I tried it without the "ConverttoYv12(matrix="rec709")" because I assumed it didn't belong there, and it didn't work. So on a lark, I put it back, tried it in AVSMeter, and it's working.

So I loaded it up in MeGUI, and in the previw screen it looks bizarre, which you told me it would. The top half is my image, but stretched, and the bottom half is a mostly green psychodelic mess.

I assume that's normal.

You mentioned something about dithering it back to 8bit, does that happen in the script? If so where, and what is the command?

Or does that happen after the 264 file is made, and same questions. Or is it somewhere after that?

poisondeathray

20th March 2016, 16:30

Bruce/Fl

20th March 2016, 17:52

Yes, it's normal, that the stacked MSB-LSB view . You won't be able to use your script or filters as-is, you'd need to convert or replace the filters to similar ones. And there is no point in using stack16 if all you are doing is using 8bit processing. It's just going to slow everything down for zero benefit. You can use dither tools to dither it back to 8bit but the method you use will depend on what filters are being used (some use 16bit RGB, so you'd need to adjust it slightly differently)

I'm thinking maybe I should try to bring chapter one here to an end.

I started this thinking I should go with Vegas for corrections, Avisynth for using Freds/Johns awesome script, then back to Vegas for mpeg-2 renders for authoring and burning to BD and DVD.

That method had extra steps and opportunities for losing quality, as you mentioned here in post 6 (http://forum.doom9.org/showthread.php?p=1759595#post1759595).

As soon as you bring it into vegas, you're working in RGB. You want to avoid unnecessary colorspace conversions, because they are lossy. This is in addition to chroma subsampling. So going back and forth in/out of vegas is a not a good idea as you convert it back to RGB again - avoidable quality loss there in your workflow. As a general rule, once you're in a certain colormodel/colorspace, you should stay there as long as possible until you have to change it for your final delivery format(s)

So, now we're doing the corrections in Vegas, Avisynth for the script, and out to a .264 file. Just need to figure out what I should use for authoring and burning.

In regards to the authoring, this was discussed earlier: (http://forum.doom9.org/showthread.php?p=1759961#post1759961)

29.97 is good for NTSC DVD if it's really 30000/1001 (29.97 is an approximation), HCEnc will work fine for that

But 30000/1001 is not supported for progressive BD at HD resolutions. It must be encoded with fake interlace, or PAFF, or MBAFF (x264 can't do PAFF). So again, what you use to author will limit your choices

What are we looking at at this point for getting the .264 ready for BD? And can HCEnc play nice with .264?

Here's kind of an oddball question, in the spirit of not reaccomplishing work. Can I do both, finish up with where I'm at now (author and burn), while still rendering at 10bit? Is there a way to somehow bring it down to 8 bit after the 10bit render out of Vegas for the purpose of running it into (or during) the MeGUi (for example, as that is what I'm using presently) process and out with .264? What I'm thinking here is not having to re-render out of Vegas, if in the future I do tackle adapting the script for a 10bit input? Now even though the Vegas rendering will be much quicker compared to the script running, (remember the.3xx fps rates I was seeing, lol) it would save me doing a different Vegas render later. (I will of course save the .veg file with the cuts/corrections info, so I won't have to redo those later)

I'm thinking not, not without even more information loss than just doing a 8 bit render would impose, but I thought I'd ask.

And just for the sake of seeing what I'm up against if/when I attack chapter 2, putting 10bit into the script, which of these are going to need changes? I believe I'm using, from the script notes:

autolevels
Deflicker
Depan
DepanEstimate
fft3dfilter
masktools2
mvtools2
RemoveDirtSSE2
removegrain
warpsharp

I believe you said earlier that some of these have no 10bit counterparts.

Or maybe table this discussion until I finish up chapter 1.

Thank you