Because I thought this was correct steps to follow when you are saving intermediate steps
It's is what I have always followed previously .. guys here have helped with processing steps .. and intermediate saves have always been in Lossless format.
I need to process in VD first ...eg: change to square pixels, set to recommended YouTube frame size size', deinterlace, then deshake, sharpen, colour adjust.
In Vegas will be collating a whole bundle of similarly treated videos, then music, transition, commentary, stills etc. ..... final render out will be 720p H264/Mp4 files (using Sony AVC/MVC codec)
+ Reply to Thread
Results 31 to 60 of 63
-
Last edited by Tafflad; 20th Feb 2016 at 17:27.
-
personally i prefer to do all adjustments in vegas, one or many fewer quality reducing steps. DVavi is not like other formats in vegas. i've never seen any advantage to using VD. i've been doing tape to dvd or file for many years.
--
"a lot of people are better dead" - prisoner KSC2-303 -
Have you found a deinterlacer & stabilizer better than QTGMC and DeShaker ? ............. keen to know, not found such (so far) in Vegas.
I am only doing this as the DV captures are of old VHS tapes and via VD seemed to me the best approach.
I will be making all the 'cosmetic' work in Vegas, and teh final render. -
That is what I thought and hence my work in VD on Deinterlacing & DeShaker ........... now I may well have an error it the steps .. and Poiniondeathray asked me to run colour bar tests ...to see what I need to do to recover.
-
The levels and color are "off" but the videos you posted so far are only part of the information, because you want to test the full workflow and effect vegas has. But it's not really relevant because you have to "fix" levels anyways in vegas because you've clamped everything earlier pre-deshaker with the coloryuv levels adjustments and you probably want to make them anyways
I've already mentioned this but Vegas doesn't handle all YUV codecs in the same way - it sometimes uses 709 , sometimes 601, sometimes studio RGB levels, sometimes PC levels. But with RGB input, you avoid all those possiblities and premutations - it also make sense if you've used deshaker (RGB). It's relatively easy to "fix" levels in vegas (black level , white level, gamma), but not so easy to make color matrix adjustments in vegas. Vegas can work in 32bit float and has much more fine control over color manipulations than avisynth. You can read more about it when you have time, read the Glenn Chan articles on Sony Vegas and colorspaces. But different export formats can get different treatment as well - vegas "expects" certain formats to be input studio RGB, yet others in computer RGB. So sometimes you have to apply a studio=>computer RGB filter or vice versa before exporting for some formats. Finally , you can usually "fix" things by frameserving and adjusting for matrices or levels in avisynth before the final format (another reason why debugmode is so popular to vegas users)
There is more than one way to do things, but I've already explained the way I would have approached it , and the reasons why.
If you want to continue from what you have, import them into vegas and adjust the levels looking at the scopes to guide your adjustments, do some exports to you intended final format and examine -
OK realise I could have done better .... so as I still have original DV captures, I'll start again ............... and hope you can help me set the steps up correctly.
I'm looking to get the sequence right, and hopefully understand why.
Do I convert the DV or not ?
Do I run deinterlace script & save as lossless in RGB32 ? or select YUY2 ? I read elsewhere I should not use RGB and instead process all colors in 16-bit YUV with HDRcore filters.
(Trying to learn but there are so many options for everything.)
So if we do this in sequence, I want to:Step 1 deinterlace, resize -> save as MagicYUV lossless
To start then is this what my Step 1 script should look like ... goal is to Deinterlace,resize & boost saturation a little.
Step 2 deshake & sharpen -> save as MagicYUV lossless
Step 3 take media into Vegas ...
Code:AVIsource("sample.avi") LanczosResize(960,height) AssumeBFF().QTGMC(Preset="slow", EZDenoise=2.0, NoisePreset="Slow" ) LanczosResize(width,720) tweak(sat=1.2,coring=false)
When I save after Step1 as Lossless MagicYUV ... that will be RGB32 ........... or do I change it to be 4:2:2 or 4:2:0 ?
Will be key if I am to avoid changing colorspace again when I reload for Step2 -
If you've already spend a lot of time on it - You can probably still do it with what you have. It's not going to be that much of a difference, just adjust the colors and levels in vegas
But there is zero benefit to upscaling before, only negatives. The "pros" are smaller filesizes, faster QTGMC and deshaker, faster & easier editing in vegas. You have more flexible options and aren't "pigeonholed" or have to switch colors back and forth between HD or SD rec709 or 601. The more times / more manipulations you do in terms of color adjustments or resizing back and forth , the more damage you incur . What if you want to make a DVD? What if you want BD? What if you want to upscale even higher ? What about UHD BD and Rec2020 in the future? If you "bake" in those choices like color so early on you limit your options or at least have to do more work or incur more damage
I would ignore HDRcore filters, and anything like tweak or color manipulations in avisynth before - you will get more control over color in vegas and can work in 32bit float
If you are doing rough cutting (unless if you plan to use most or all of the footage, even the dead space like pointing camera at the ground etc...) ,I would do that first always. But some people feel they have to include everything ughh... This means less processing time for QTGMC, and deshaker . As for step 1 , I would only use QTGMC as the input into deshaker if the levels are fine. You can keep it YV12, vdub will automatically convert to RGB using 601 (which is correct for SD).
If you don't have a good idea of levels and starting point, you should learn about Y' levels. If your levels are legal, there is nothing to worry about and you don't have to make the PC=>TV "blind" clamp. The concern is that when you convert to RGB pre-deshaker, you will clip data with that conversion. But a smarter way is to examine the actual footage and make the proper adjustment for that footage. That might include adjusting the capture setup in the first place
For vegas I would use an RGB intermediate coming out of deshaker. It's RGB anyways, at that point so no use degrading it any farther. Vegas also works in RGB.
You can make adjustments in vegas, and final matrix adjustments geared to your final format goal. Debugmode is very useful in that regard -
Just happened to see this thread and thought I might add a few comments regarding your workflow. The only difference, is that I've started with 8mm or hi8 and converted to DV using a Sony GV-D200. You've taken the approach of doing most of your pre-processing before importing into Vegas. I've taken a somewhat different approach in that I begin by importing my DV files onto the Vegas timeline and first do basic cuts editing. Usually (at least in my case), I only want only a percentage of the original footage, so it's much more efficient to do the Avisynth-Virtualdub processing on just those events that I want for the final production.
To easily do this, I've prepared a number of scripts that follow this basic process. For selected events on the timeline: (1) render the first event to a temporary file using a lossless codec (or whatever codec you want--I currently use Magic YUV); (2) open the selected Avisynth file using Virtualdub; (3) load the Virtualdbub settings file which essentially specifiies which compression codec will be used for render (again, I use Magic YUV); (4) do the virtualdub render; (5) add the rendered file as a Take to the selected event and (6) repeat the process for the remaining events that have been selected. Once set up, the process is pretty much automated. I usually have Taskbar icons for running these scripts. Once I've applied my chosen avisynth-virtualdub filters, I then have another script that simply renders each event to whatever codec I've chosen (E.g. I use XAVC S with HD footage) and adds the result as another Take. Once happy, I then delete the lossless avi's and simply use that Take for final editing and also archiving. The nice thing about adding the result of each Avisynth-Virtualdub process as a Take, it enables you to quickly see its effects and also see if there have been color shifts.
Some of the scripts that I have include: Deinterlacing and resizing using QTGMC; stabilization using Deshaker; noise reduction using some of John Meyer's scripts, fisheye removal from GoPro footage, etc. With the exception of the Deshaker script, the others use a common structure that one can tailor to whatever avisynth script you want to run. If there is any interest, I can make available a sample script on Dropbox.
Regarding your script, as others have suggested, I would do the resize after deinterlace and wait until Vegas to do color tweaking. I would also try running the MT version of Avisynth, which will speed things up significantly. Here is the script that I've been using. As you can see, I've tried quite a few different options. For my footage, I've found the quality of the deinterlace using SourceMatch to be significantly better. My suggestion would be to try different options and judge for yourself.
wwaag
Code:SetMemoryMax(1000) SetMTMode(5,12) AVISource("G:\Render Previews\ww.avi").killaudio().AssumeBFF.ConvertToYV12(matrix="Rec601", interlaced=true) # Crop(12,2,-4,-6) #ADVC-100 Crop(6,2,-6,-6) #Canon # CropBottom(4) #sony dv # Crop(8,2,-8,-6) SetMTMode(2) #QTGMC( source, Preset="Slow") #QTGMC( source, Preset="Slow", Tr2=2) #QTGMC( source, Preset="Slower", SourceMatch=3 ) #QTGMC( source, Preset="Slow", SourceMatch=1,InputType=0, TR2=2, Sharpness=0.4, ProgSADMask=5.0, EdiThreads=1 ) #QTGMC( source, Preset="Medium", SourceMatch=2 ) #QTGMC( source, Preset="Slow", Sharpness=0.2) #QTGMC( source, Preset="Slow", InputType=0, TR2=2, ProgSADMask=5.0, EdiThreads=1 ) QTGMC(Preset="Slower", SourceMatch=2,InputType=0, TR2=3, Sharpness=0.4, EdiThreads=1) #QTGMC(Preset="Slower", SourceMatch=2,InputType=0, TR2=3, Sharpness=0.4, EdiThreads=1, NoiseProcess=1, NoiseRestore=0.0, Sigma=4.0) Spline36Resize (960,720)
-
I agree .. I always coarse cut out in VD .. losing the garbage at the start.
So if I leave my current project files 'as is' and finish in Vegas would like to get the correct process for the 2 steps.
If I follow ...
Step 1 .... run script I have ... save output as MagicYUV 4.2.0 (as original is 4.2.0)
Step 2 ... load into VD, run deshaker passes , and save as MagicYUV RGB32
Step 3 ... load files into Vegas .. and color adjust etc. in there.
I can set the levels there if needed by changing with Sony Levels fx 'computerRGB -> StudioRGB' -
Hi Wayne .. thanks for joining in.
Quite a few things in that script I have not used before ... sourcematch being one of them ... I'll try it out.
You are setting SetMTMode(2) so I assume I would then need a MultiThread version of Avisynth - and do I need to get new versions of the plugins ?
Be interested in any scripts you care to share.
I follow some of what you describe .. probably need to try it out to get the sequence. -
You are setting SetMTMode(2) so I assume I would then need a MultiThread version of Avisynth - and do I need to get new versions of the plugins ?
Yes. Here is a link to Avisynth 2.6MT.
http://forum.doom9.org/showthread.php?t=148782
I'm still using an old version from 2012. No new versions of the plug-in are needed, at least from QTGMC. If you look in the QTGMC html help file, there is discussion on the use of MT. I must admit its a bit twitchy and I do get the odd crash on occasion, but it really boosts CPU usage--up to near 100% on the fish-eye removal script. If you can get it to work, it really is a lot faster.
I'll upload the sample script and send you a PM with the link.
wwaag -
Just a follow-up on the speed difference. Using one of John Meyer's denoise scripts, CPU usage is pegged at near 100% when running MT. If you change the script to cancel MT, CPU usage dropped to 15% and render time increased nearly six fold. Again, it's well worth it if you can get it to work.
wwaag -
You're obviously taking a great deal of care with this project, in your efforts to get the best from your sources. I think you have mentioned posting to You Tube, in addition to your other intentions for the final edits?
The problem with the care you are taking to optimise your re-sizing is that You tube will resize 576 to 480. For example, a recent 720 x 576 clip I uploaded was resized automatically to 600 x 480 by You Tube. It doesn't seem to have affected the quality too much ... and it was only a clip from a VHS capture anyway.
There is a school of thought that recommends resizing 4:3 clips to 16:9, using borders to maintain the correct aspect ratio of the video itself.
By uploading a clip to You tube as - say - 1280 x 720, you avoid You Tube resizing the clip, and also get the benefit of 'forcing' You Tube to re-encode (which they always do) at their higher 'HD' bit rate.
Whether that offers any significant improvement you would have to decide for yourself, by trying it out with a short clip.
But if you find it does offer an improved result, it might be worth considering how to incorporate that option into your work flow before you proceed to process a lot of clips?
Just a thought... -
Pippas - not so much just this project
want to understand and formulate the best workflow for future projects ........... have a load of similar VHS capture .. if I get workflow right at start will help me.
The reason I was loading at 960x720 was the exchange in https://forum.videohelp.com/threads/376765-Progressive/page2
esp around post #58
As you say I would still get same image, and possibly maintain it better by using 1280x720 ........... will that leave image alone and just force black borders ......... which would be OK ... just don't want video 'stretched to fit'Last edited by Tafflad; 22nd Feb 2016 at 06:28.
-
I can also vouch for QTGMC MT. I never run it in ST thread mode. It is one of the few use cases that justifies spending money on an i7. The increase in speed goes from one core at ~13% cpu usage to all eight threads on my machine at nearly 100% cpu usage, so an 8-fold increase in speed. These are not some theoretical benchmarks but real world experience.
The Avisynth wiki and the doom9 thread on QTGMC are both detailed enough to get anyone up and running in MT. I have a build image for my PC that I constantly reload (a small image and an ssd make it easy), and I haven't included the QTGMC MT as part of my build. So even though I feel like I am constantly re-installing the MT dll's, it is easy enough that I don't sweat including it in my build. -
I think to be certain of higher bit rate encoding you need to upload as a 1280 x 720 file. That would mean you add the borders yourself to ensure both correct aspect ratio display and to ensure You tube doesn't restrict the bit rate to their 'SD' model.
I uploaded a couple of short clips - (it's only of an Avisynth animation I made a while back)- to compare two forms of SD capture: DV with a Canopus converter and HQX with an 'EZcap'116 (a real one, not a fake!)
The original clip was at 1280 x 720, and of course being in 'PAL land' the captures were 720 x 576.
I re-sized one version of the clip to 1024x576, and one version to 1280 x 720 , just to see how different the You Tube encoding would be.
....The answer was quite a lot!
The 1280 x 720 'HD' version of the clip is here: https://www.youtube.com/watch?v=zLk0NYq9jaA
and the 1024 x 576 'SD' version here: https://www.youtube.com/watch?v=gidbItbRA50&feature=youtu.be
As you can see, there is quite a difference. Understandably with the 1280 original clip, but also with the SD captured versions that follow.
I think it's probably worth adding borders to an SD clip and 'forcing' the size to be 1280 x 720, for better You tube encoding and replay.
The downloaded version of both clips is very different as well.
The 1280 x 720 stays at the same display size. You tube re-encoded the 1024 x 576 version as 640 x 360 ... quite a drop in resolution! -
Assuming you start with a clip of size 960 x 720 ... simply open the file in VD, select the resize filter and select 'Letterbox to aspect ratio 16:9'
That will give you a 1280 x 720 frame size, with the 4:3 video at maximum size in the centre...
But of course because you would be using a VD filter, you need to use full processing mode, so you would need to minimise anypossible colour space conversion 'damage' .....
There's probably a way of doing it with Avisynth without any colour space conversions?.....I'm sure one of the experts will know.... -
AddBorders()
But be careful when using this in YUV space. Depending on the chroma subsampling, it may require border sizes being multiples of at least 2, maybe even 4 in some cases.
In VirtualDub 1.10+ (possibly even earlier, don't remember the exact version of first implementation), some basic VirtualDub filters even work in YUV space, not all of them require RGB conversion anymore. -
Before hard-coding pillarboxing, ensure it's actually necessary.
-
-
Last edited by Tafflad; 24th Feb 2016 at 09:42.
-
The Ut codec suite is an OpenSource project, supporting VfW (codec as encoder and decoder), DirectShow (filter as decoder), and even with a QuickTime component. Due to the source being available, it is also implemented in libavcodec based projects like ffmpeg. Summing it up: It is more versatile than MagicYUV.
Having a VfW codec installed should not be an issue for Vegas on its own. Whether Vegas can handle this format or not, is a different topic. Alternatively it may support the DirectShow decoder. Or even the QuickTime component. Ut gives you a variety of choices. -
The suggestion was to do this to force streaming site to a particular fame size .... do you not think this is good option ?
No, definitely not. Since you are going to use Vegas, just import those files and let the final render produce the pillar boxes. Moreover, you have the option of putting something else on a track below to eliminate the black bars completely, much like they do in newscasting. It could be a moving graphic or simply a copy of the file stretched to 16 x9, lightened and blurred. If you have a 1280 x 720 image already with black bars, it's much more difficult since Vegas Movie Studio doesn't have a masking capability. In any case, just keep your 960 x 720 frame size and you will have more options.
Regarding UT Video vs MagicYUV, I've used both. I've experienced some color shifts with UT Video when going back and forth between Vegas and Virtualdub and for that reason prefer Magic YUV. Moreover, preview performance inside of Vegas is better. My suggestion though--try them both. After all, these digital intermediates are not for archiving--once finished, they're usually deleted.
wwaag
Similar Threads
-
Media choice DVD +R or -R
By Tafflad in forum Authoring (DVD)Replies: 4Last Post: 11th Dec 2015, 06:14 -
Converting Avi -> MP4 losless? and avidemux questions
By VideoNoob123 in forum Video ConversionReplies: 3Last Post: 6th Oct 2014, 06:50 -
Lossless to Losless audio conversion (Dolby Truehd<>PCM<>DTS-HD)
By maxrockpro in forum AudioReplies: 3Last Post: 3rd Mar 2013, 12:39 -
Choice of HD format
By Immortal25 in forum EditingReplies: 6Last Post: 8th Jul 2012, 00:28 -
need free program to quickly losless crop an mpeg2 740x480 to 720x480
By wolfdogg in forum Newbie / General discussionsReplies: 5Last Post: 13th May 2011, 17:49