VideoHelp Forum




+ Reply to Thread
Results 1 to 12 of 12
  1. Member
    Join Date
    Jan 2013
    Location
    Florida
    Search Comp PM
    I have been working on a workflow of running QTGMC for deinterlacing of some Hi8 tape transfers I have in VDub, then taking that result, loading it in Vegas for some small edits, and rendering it out of Vegas as progressive avi, using the NTSC DV codec. (Target output is a computer)

    I was having difficulty in selecting a codec in VDub that didn't mess with the deinterlaced output, so I have been just letting it go uncompressed. Large files, but I have enough space for some large files, Vegas takes it and renders it out close to its original size. No problem.

    But I think I want to add in Deshaker on a few of them. Is there a smart way to do this, without making ridiculously large files? IOW, taking the large output of QTGMC run, loading it back in to VDub for Deshaker and getting even LARGER output file to feed Vegas? A file of that size would tax my space reserves probably too far.

    I'm pretty sure I shouldn't run the QTGMC and Deshaker processes at the same time in VDub.

    I was doing some slight cropping in Vegas due to some bad edges on the transfers, I would most likely switch that over to prior to the Deshaker run for obvious reasons.

    I've used depan in an avisynth script (with a lot of help), but I'm not really avisynth fluent, so I think I want to stick with Deshaker for the image stabilization.
    Quote Quote  
  2. Originally Posted by Bruce/Fl View Post
    I was doing some slight cropping in Vegas due to some bad edges on the transfers...
    Any reason you're not doing that in AviSynth? If you've mastered QTGMC, then learning how to crop can't be all that hard. Why do you need Vegas at all?
    Quote Quote  
  3. Member
    Join Date
    Jan 2013
    Location
    Florida
    Search Comp PM
    Originally Posted by manono View Post
    Originally Posted by Bruce/Fl View Post
    I was doing some slight cropping in Vegas due to some bad edges on the transfers...
    Any reason you're not doing that in AviSynth? If you've mastered QTGMC, then learning how to crop can't be all that hard. Why do you need Vegas at all?
    Doing some edits, some transitions, mild color and exposure tweaks, and also taking advantage of its selections in rendering that gets the file size back down.

    The files are to give to a person in my Hi8 videos, trying to keep the size manageable.

    And I wouldn't say I have mastered QTGMC, not by any stretch of the imagination. I'm using it pretty much with the presets, they work well for my situation.
    Quote Quote  
  4. Member Skiller's Avatar
    Join Date
    Oct 2013
    Location
    Germany
    Search PM
    For shaky VHS transfers that need some editing in Vegas my workflow is this:

    Cropping and QTGMC [saving as lossless intermediate], denoising and conversion to RGB for Deshaker and Vegas [saving as lossless intermediate], Deshaker [saving as lossless intermediate], Vegas [saving as lossless intermediate], conversion to YUV and 25i if needed (for DVD) and encoding out of AviSynth.

    Yeah that's 4 intermediate lossless AVI files. Although it is not necessary to keep them all until the end. You don't need to keep more than 2 at a time.


    Originally Posted by Bruce/Fl View Post
    But I think I want to add in Deshaker on a few of them. Is there a smart way to do this, without making ridiculously large files?
    Well, fist of all that depends on what you call large. Lossless intermediates will result in file sizes in the range of 35-75 GiB per hour (depending on the color space and frame rate). Is that managable for you?
    Technically you don't have to save as many intermediate files as I do but here is why I prefer to use so many: it's just much less of a headache! Need to re-adjust Deshaker's settings? Just run Deshaker again, no need to run QTGMC and denoising all over again.


    Originally Posted by Bruce/Fl View Post
    I'm pretty sure I shouldn't run the QTGMC and Deshaker processes at the same time in VDub.
    That would take forever due to the 2 passes needed by Deshaker, so no good idea indeed.


    Originally Posted by Bruce/Fl View Post
    so I think I want to stick with Deshaker for the image stabilization.
    I would stick with Deshaker as well. Depan would be more conveniet to use in AviSynth but Deshaker produces way better results (in my opinion).
    Last edited by Skiller; 28th Mar 2016 at 07:57.
    Quote Quote  
  5. Member
    Join Date
    Jan 2013
    Location
    Florida
    Search Comp PM
    Originally Posted by Skiller View Post
    Well, fist of all that depends on what you call large. Lossless intermediates will result in file sizes in the range of 35-75 GiB per hour (depending on the color space and frame rate). Is that managable for you?
    I'll have to do a test run to see what the end result will be.

    I was going under the assumption that the runs through VDub would both multiply the size by the same degree (ratio). For example, my 30 minute file being 7 gig, after its uncompressed VDub QTGMC run being, say, 60 gig. Then loading that 60 gig output for a second run (for deshaker), that runs uncompressed its output would be the same ratio larger, which in this case would be 514 gig. whoa!

    I'll do a small section and see how it plays out.
    Quote Quote  
  6. Whoa talk about inflation

    Nope - uncompressed video in the same color model/space will be the same size exactly to the same byte.

    If you had used QTGMC in YV12, it will become larger in filesize once it's in RGB because it's not subsampled. But once it's in 8bit RGB from vdub (deshaker is RGB only), it will be the same size (that's the largest it will be) .

    You can use various lossless compression codecs to reduce the filesize
    Quote Quote  
  7. Member Skiller's Avatar
    Join Date
    Oct 2013
    Location
    Germany
    Search PM
    I highly recommend MagicYUV. It's extremely fast on modern CPUs, very efficient and easy to use. People keep using HuffYUV these days, but I think HuffYUV is totally outperformed by MagicYUV in every way so there is no reason not to prefer it.
    Quote Quote  
  8. Originally Posted by Skiller View Post
    I highly recommend MagicYUV. It's extremely fast on modern CPUs, very efficient and easy to use. People keep using HuffYUV these days, but I think HuffYUV is totally outperformed by MagicYUV in every way so there is no reason not to prefer it.
    I thought most people used utvideo for lossless intermediates these days? Although I had to abandon the use of lossless intermediates and resort to raw UYVY for Resolve.
    Quote Quote  
  9. magicyuv is slightly faster in terms of decoding speed, and has slightly better compression than UT. It's the new "king"

    The potential problems with magicyuv are it's not open source (no ffmpeg encoding support for example, and if the 1 developer quits, it's a dead project with no improvements.), compatibility with programs (not as stable or throroughly tested in production environments - for example it's less stable in premiere, whereas UT has been thoroughly tested and can even be used as the "preview" codec for render previews - in RGB workflows this makes exporting very fast when using render previews for AME)
    Quote Quote  
  10. Member
    Join Date
    Jan 2013
    Location
    Florida
    Search Comp PM
    This is probably something obvious, but I am having a really hard time maintaining my DAR while running QTGMC.

    My input file is a 720x480 avi showing a DAR of 4:3 (Image is letterboxed, actual image is 640x480, which is of course, 4:3). Fine, it is Hi8 from back when the aspect ratio was 4:3.

    Once I run the very basic QTGMC script (via VDub), it comes out 3:2, and obviously stretched some from "normal".

    This is the script:

    AVISource("c:/xxx.xxx.avi")
    AssumeBFF()
    QTGMC( Preset="slow" )
    Selecteven()
    That's it. And it insists on changing it. What am I missing?

    (I tried with and without the assumeBFF also, just to see. No difference.)

    I adjusted project properties in Vegas to 640x480 and re-rendered, (but I couldn't override the 720x480 on the render) and same result.

    It seems like everything I try is fruitless. I went through all the menu items in VDub as well looking for something to tweak, and I didn't see anything.

    I simply want my interlaced 640x480 file deinterlaced using QTGMC, while maintaining the DAR. Is that too much to ask? (Yes, getting a little flustered here, heh)
    Quote Quote  
  11. Originally Posted by Bruce/Fl View Post
    I simply want my interlaced 640x480 file deinterlaced using QTGMC, while maintaining the DAR. Is that too much to ask? (Yes, getting a little flustered here, heh)
    Since your source is 720x480 and you didn't resize to 640x480, what makes you think it's supposed to be 640x480? If you want 640x480, then add a line to your script:

    LanczosResize(640,480)

    Otherwise the only way to get it to display as 4:3 is to set a SAR in your encoder for whatever the intended final format is. AviSynth has nothing to do with that.
    Once I run the very basic QTGMC script (via VDub), it comes out 3:2, and obviously stretched some from "normal".
    It was 3:2 to begin with (720:480=3:2). QTGMC changed nothing.
    Quote Quote  
  12. Originally Posted by Bruce/Fl View Post
    This is the script:

    AVISource("c:/xxx.xxx.avi")
    AssumeBFF()
    QTGMC( Preset="slow" )
    Selecteven()
    That's it. And it insists on changing it. What am I missing?
    AviSynth has no understanding of the sampling aspect ratio or the display aspect ratio. A frame of pixels is just a frame of pixels. So your 720x480 frame is just that, a frame 720 pixels wide and 480 pixels tall, a ratio of 3:2. Since the SAR and DAR information is gone it's up to you to either resize to a 4:3 frame size or flag the encoded video as 4:3 DAR so that the player plays the video with the correct display aspect ratio.

    In general

    Code:
    DAR = FAR * SAR
    DAR = Display aspect ratio, the final shape of the picture (4:3, 16:9, etc.)
    FAR = Frame aspect ratio, the relative frame dimensions
    SAR = Sampling aspect ratio the relative distance between samples horizontally and vertically.

    SAR can also be thought of as the shape of individual pixels, square or rectangular. For example:

    Code:
    DAR = FAR * SAR
    DAR = 720/480 * 8/9
    DAR = 720 * 8 / 480 / 9
    DAR = 1.33333... = 4:3.
    Last edited by jagabo; 5th Apr 2016 at 06:52.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!