VideoHelp Forum
+ Reply to Thread
Results 1 to 25 of 25
Thread
  1. I have screen shake in my NTSC 29.97 fps interlaced MPEG2 video. I am using the following script to clean it up and fix the screen shake. I need to mention SeparateFields() SelectEvery(4,0,3) Weave() twice otherwise the frame rate will be doubled but that caused the encoding speed to go from 14 fps to under 1 fps!

    Is there a 1 line alternative I could use instead of twice using SeparateFields() SelectEvery(4,0,3) Weave()? At the moment if I just mention SeparateFields() SelectEvery(4,0,3) Weave() once then the frame rate is 59.94 fps but I want it to be 29.97.

    Code:
    If I do this it encodes quickly but takes twice as long as it's encoding at double the normal frame rate. However if I add the commented line then sit encodes at the correct bitrate but only 
    encodes at 1 fps
    
    setmtmode(5,9)
    Mpeg2Source("E:\Video.d2v", CPU=6)
    setmtmode(2)
    
    McTemporalDenoise(settings="medium", interlaced=true) 
    
    Load_Stdcall_plugin("C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll")
    AssumeTFF() Yadif(mode=1, order=1) mdata = DePanEstimate(dxmax=0) Vinverse() DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4)
    
    SeparateFields() SelectEvery(4,0,3) Weave()
    
    AssumeTFF() 
    QTGMC(Preset="Super Fast") # Removes interlacing artefacts. 
    Vinverse() RemoveSpots() AddGrainC(var=1.0,uvar=1.0) SeparateFields() SelectEvery(4,0,3) Weave() 
    
    Tweak(Hue=0, Sat=0.8, Bright=-0, Cont=1.0, Coring=False) 
    
    Crop(0,0,-2,-8) #  Bottom 8 pixels crop is required even if you don't have anything to crop to prevent the bottom of the picture moving up and down
    AddBorders(8,4,10,4)
    Last edited by VideoFanatic; 2nd Mar 2013 at 09:21.
    Quote Quote  
  2. Member
    Join Date
    Jan 2003
    Location
    India
    Search Comp PM
    QTGMC is a deinterlacing script Yadif is a deinterlacer, the separatefields,selectevery, weave combo twice
    Aren't you overdoing it a bit?
    If you are using qtgmc you do not need to use any other deinterlacer
    just use qtgmc +selecteven() or selectodd() if you do not want doubling of fps

    depanstabilize is the only thing there removing shake in the video.
    Quote Quote  
  3. Why don't you use QTGMC to produce progressive frames first, do all your work on those progressive frames, then reinterlace at the end if necessary. What you're doing now is insane.
    Quote Quote  
  4. So do I definitely not need the following Yadif line then? I just assumed it was part of the screen shake script.

    Yaddif(mode=1, order=1)

    So will the following be OK to fix the screen shake, denoise and keep it as 29.97 interlaced?

    Code:
    McTemporalDenoise(settings="medium", interlaced=true) 
    
    AssumeTFF() 
    QTGMC(Preset="Super Fast")
    RemoveSpots() AddGrainC(var=1.0,uvar=1.0) 
    
    mdata = DePanEstimate(dxmax=0) Vinverse() DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4)
    
    SeparateFields() SelectEvery(4,0,3) Weave()
    Quote Quote  
  5. You would be much better off if you took the time to understand how things work rather than simply copying and pasting multiple scripts together.
    Quote Quote  
  6. I tried this but it's still encoding at under 1 fps:

    Code:
    McTemporalDenoise(settings="medium", interlaced=true)   
    AssumeTFF()  
    QTGMC(Preset="Super Fast") 
    RemoveSpots() AddGrainC(var=1.0,uvar=1.0)  
    
    mdata = DePanEstimate(dxmax=0) Vinverse() DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4) 
    
    SeparateFields() SelectEvery(4,0,3) Weave()
    I'm not sure what I'm supposed to do to get it to encode at a normal speed.
    Quote Quote  
  7. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Originally Posted by jagabo View Post
    You would be much better off if you took the time to understand how things work rather than simply copying and pasting multiple scripts together.
    Agreed.

    What does "screen shake" mean? Does it mean frame hopping?
    Last edited by sanlyn; 25th Mar 2014 at 11:57.
    Quote Quote  
  8. The screen moves up and down due to old VHS equipment. Can anyone help me with this encoding speed problem?
    Quote Quote  
  9. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    sample, please.
    Last edited by sanlyn; 25th Mar 2014 at 11:57.
    Quote Quote  
  10. Sample. I removed Yadif and now I have this script but it still encodes slowly for some reason:

    Code:
    setmtmode(5,9)
    Mpeg2Source("E:\2 = New\z = Encode\ECW Hardcore TV October 13 1998 Fixed.d2v", CPU=6)
    setmtmode(2)
    
    McTemporalDenoise(settings="medium", interlaced=true) 
    
    AssumeTFF() 
    QTGMC(Preset="Super Fast") 
    RemoveSpots() AddGrainC(var=1.0,uvar=1.0) 
    
    mdata = DePanEstimate(dxmax=0) Vinverse() DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4)
    
    SeparateFields() SelectEvery(4,0,3) Weave() 
    
    Tweak(Hue=0, Sat=0.8, Bright=-0, Cont=1.0, Coring=False) 
    
    Crop(0,0,-2,-8) #  Bottom 8 pixels crop is required even if you don't have anything to crop to prevent the bottom of the picture moving up and down
    AddBorders(8,4,10,4)
    Quote Quote  
  11. More threads? Why are you running VInverse() between DepanEstimate() and DepanStabilize()?

    This sequence:

    Code:
    setmtmode(5,8)
    Mpeg2Source("E:\Downloads\Shake.d2v", CPU=6, Info=3) 
    setmtmode(2)
    
    AssumeTFF() 
    QTGMC(Preset="Super Fast") 
    
    mdata = DePanEstimate(dxmax=0)
    DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4)
    
    McTemporalDenoise(settings="medium") 
    RemoveSpots()
    AddGrainC(var=1.0,uvar=1.0) 
    Vinverse()
    
    Tweak(Hue=0, Sat=0.8, Bright=-0, Cont=1.0, Coring=False) 
    
    Crop(0,0,-2,-8) #  Bottom 8 pixels crop is required even if you don't have anything to crop to prevent the bottom of the picture moving up and down
    AddBorders(8,4,10,4)
    
    SeparateFields()
    SelectEvery(4,0,3)
    Weave()
    gives me about 5 fps on my i5 2500K. Without the final interlacing sequence it gives about 11 fps. I left all your filters in though I question the use of some of them. And I'm not evaluating the final result, only the execution speed.

    Using SeparateFields().nnedi3(dh=true) rather than QTGMC() gives better image quality when the video is bouncing, worse when it's still. Worth a look. nnedi3 on the left, qtgmc on the right:

    Click image for larger version

Name:	comp.jpg
Views:	856
Size:	111.0 KB
ID:	16582

    Code:
    setmtmode(5,8)
    
    function DebounceVertical(clip source)
    {
      last=source
      mdata = DePanEstimate(dxmax=0)
      DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4)
    }
    
    src=Mpeg2Source("E:\Downloads\Shake.d2v", CPU=6, Info=3).Trim(0,200)
    setmtmode(2)
    
    ned=SeparateFields(src).nnedi3(dh=true).DebounceVertical()
    qtg=QTGMC(src).DebounceVertical()
    StackHorizontal(ned,qtg)
    Image Attached Files
    Last edited by jagabo; 2nd Mar 2013 at 12:09.
    Quote Quote  
  12. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Code:
    SmoothLevels(16, 1.0, 255, 16, 230,chroma=200,limiter=2,tvrange=true)
    ColorYUV(off_y=-4)
    ColorYUV(cont_u=-20,off_u=-2)
    AssumeTFF().SeparateFields()
    In1 = last
    e=in1.SelectEven().stab(dymax=8)
    o=in1.SelectOdd().stab(dymax=8)
    eo=Interleave(e,o).Weave().Crop(2,0,0,-8).AddBorders(2,4,0,4)
    eo
    QTGMC(preset="super fast")
    Stab()
    RemoveSpots()
    AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()
    Crop(2,8,0,-4).AddBorders(2,4,0,8)
    return last
    
    Last edited by sanlyn; 25th Mar 2014 at 11:57.
    Quote Quote  
  13. Originally Posted by sanlyn View Post
    Code:
    SeparateFields()
    In1 = last
    e=in1.SelectEven().stab(dymax=8)
    o=in1.SelectOdd().stab(dymax=8)
    eo=Interleave(e,o)
    That gave really bad results when I tried it. But your whole script works ok. Ah, I see why. I was using VideoFanatic's DepanEstimate() DepanStabilize() sequence, not Stab().
    Last edited by jagabo; 2nd Mar 2013 at 13:09.
    Quote Quote  
  14. This seems to work and I'm getting over 12 fps. The key seems to be having the bolded line after the Depan line and not above it:
    Code:
    setmtmode(5,9)
    Mpeg2Source("E:\Video.d2v", CPU=6)
    setmtmode(2)
    
    McTemporalDenoise(settings="medium", interlaced=true) 
    
    AssumeTFF() 
    QTGMC(Preset="Super Fast") 
    
    mdata = DePanEstimate(dxmax=0)  DePanStabilize(last, data=mdata, initzoom=1.05, dxmax=0, dymax=4)
    
    Vinverse() RemoveSpots() AddGrainC(var=1.0,uvar=1.0) 
    SeparateFields() SelectEvery(4,0,3) Weave() 
    
    Tweak(Hue=0, Sat=0.8, Bright=-0, Cont=1.0, Coring=False) 
    
    Crop(0,0,-2,-8) #  Bottom 8 pixels crop is required even if you don't have anything to crop to prevent the bottom of the picture moving up and down
    AddBorders(8,4,10,4)
    Last edited by VideoFanatic; 2nd Mar 2013 at 13:30.
    Quote Quote  
  15. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Originally Posted by jagabo View Post
    Originally Posted by sanlyn View Post
    Code:
    SeparateFields()
    In1 = last
    e=in1.SelectEven().stab(dymax=8)
    o=in1.SelectOdd().stab(dymax=8)
    eo=Interleave(e,o)
    That gave really bad results when I tried it. But your whole script works ok. Ah, I see why. I was using VideoFanatic's DepanEstimate() DepanStabilize() sequence, not Stab().
    I stuck with Stab, but I kept wondering why there was so much jitter and what looked like field misalignment. So I tried SeparateFields and thought -- maybe -- stab will "level" the fields out ? ? Apparently it did. Then, deinterlace + another stab() worked.

    The other stabilizers gave a jittery image and geometric distortion.

    Keeping your suggested script as well. Will try it on my own project later.
    Last edited by sanlyn; 2nd Mar 2013 at 16:49.
    Quote Quote  
  16. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    Oops. Forgot to post the output. Still some noise in the darks, but the object was to stop frame hopping. Some dark ghosting from the original tape is evident, and watch banding in the black background. Upping the bitrate helps. This is how many generations, now? Five? Ten?
    Image Attached Files
    Quote Quote  
  17. Originally Posted by sanlyn View Post
    I stuck with Stab, but I kept wondering why there was so much jitter and what looked like field misalignment. So I tried SeparateFields and thought -- maybe -- stab will "level" the fields out ? ? Apparently it did.
    Yes, that's what I was thinking too. But when I did it with the Depan sequence the OP used it the jitter got even worse. After thinking about it more I reasoned that deshaking fields might exacerbate the problem rather than make it better. This type of vertical jitter happens when fields are shifted up or down by two scan lines of the frame (one scan line of the field). The deshaker might just as well move the good field down rather than the bad field up (or vice versa). That might cause even more problems for QTGMC() later. But the problem I was seeing was Depan making the shake worse rather than better. Whereas Stab() indeed reduced the shaking. QTGMC() still has problems with some frames, leaving blurred or double exposures. My method using nnedi3 looked better on those frames, but worse on others.
    Quote Quote  
  18. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    I've had to clean up video by running it thru one set of filters, then a different set, then combing good and bad frames from each. That's pretty much a frame-by-frame process (!). An hour of such video, and I'd be ready for the squirrel cage.

    I wonder about this code from VideoFanatic:
    Code:
    Crop(0,0,-2,-8)
    AddBorders(8,4,10,4)
    This changes the frame size from the original 704x480 to 720x480 by adding black borders. I don't see that the video will display at 4:3 correctly. If the borders are retained they would be part of the display; it would look close to 4:3, but the actual image would be "squished" (narrowed) by 20 pixels. ?

    But I'm using a different encoder.
    Last edited by sanlyn; 25th Mar 2014 at 11:58.
    Quote Quote  
  19. That's the first I've heard about squished images! Bluray only supports 720 x 480 so I added the borders like I was told to do. If it was 704 x 480 in the video editor and 4:3 already then how can adding borders to make up 720 x 480 squish the image out of proportion? Why would using a different encoder matter?
    Last edited by VideoFanatic; 2nd Mar 2013 at 22:15.
    Quote Quote  
  20. Originally Posted by VideoFanatic View Post
    That's the first I've heard about squished images! Bluray only supports 720 x 480 so I added the borders. If it was 704 x 480 in the video editor and 4:3 already then how can adding borders to make up 720 x 480 squish the image out of proportion? Why would using a different encoder matter?
    The MPEG 2 spec (used by DVD and Blu-ray) says the 4:3 image is contained in the full 720x480 frame. That's at odds with the rec.601 digital video capture spec (followed by most analog capture devices) that says the 4:3 image is in the 704x480 portion of the 720x480 frame. Technically, you should enlarge the inner 704 up to 720 (ie, resize, not add borders) when making a DVD or Blu-ray disc. But nobody in the industry cares. Commercial DVDs made from analog sources usually don't bother. Some DVDs go by one rule, some by the other. Even DVD players are schizophrenic. They usually go by MPEG 2 rules when upscaling for HDMI output, rec.601 rules for composite and s-video output. So no matter what you do, one or the other will have the wrong aspect ratio. In the end, you can't see the ~2 difference anyway.
    Last edited by jagabo; 2nd Mar 2013 at 22:28.
    Quote Quote  
  21. Member 2Bdecided's Avatar
    Join Date
    Nov 2007
    Location
    United Kingdom
    Search Comp PM
    Originally Posted by jagabo View Post
    The MPEG 2 spec (used by DVD and Blu-ray) says the 4:3 image is contained in the full 720x480 frame.
    It says that, in the absence of some extension I've forgotten the name of, the full frame is 4x3. (or whatever you set it to, the options being 4x3, 16x9, or square pixels)

    So if you encode 720x480, MPEG-2 says that is 4x3.
    Similarly if you encode 704x480, MPEG-2 says that is 4x3.

    That MPEG-2 spec is clearly wrong because for nearly a decade after it was written there was no equipment that could achieve both these things, due to fixed 13.5MHz sampling rate and conventionally calibrated monitors.

    If you encode 704x480 there's no contradiction or confusion, and no black bars either. It's the best choice for 4x3 DVD. I've no idea if this is a legal size for BluRay though.

    In the end, you can't see the ~2 difference anyway.
    Well, if you compare it's visible, but hard to spot without a comparison. You can spot the black bars when playing back on a PC though.

    Cheers,
    David.
    Quote Quote  
  22. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    I see nothing in the forum's HD spec sheet about 704x480, so I'm assuming it's not a valid encoded frame size. About 2004 or 2005, I saw posts in this forum by lordsmurf and another regular member who posted tests and images showing that for 4:3 images off VHS (I don't know about other 4:3 sources, such as cable tv), the 704x480 frame was "ideal" for 4:3 source images. 720x480 would slightly displace a 4x3 image and crop off part of one side -- usually a few pixels off the left -- so that 720x480 pixels could accommodate the height of the 4x3 image. 704x480 was preferred for captur and encoding because the pixel ratio of 704x480 was closer to that of 4x3 source than was 720x480.

    So at the time I had two complete VHS captures, captured at 640x480. I noted when encoding the the movie titles in 720x480 that a part of the left side was missing (wide titles were nearly against the left border), while at 704x480 there was more of the original image at the left-hand side, even if a smaller portion had been cropped. The same was true for TV playback of those DVD encodes. I just spent an hour looking for that post, but can't find it.

    I still have those two 704x480 DVD's somewhere, have used 704x480 in other projects, and have a couple of retail DVD's that use that frame size. Now, what the hell happens with 16:9 video in a 704x480 frame is anyone's guess, but I've never seen 704x480 used for wide screen video. Also have a silent-film retail DVD, a 1918 movie shot on 16mm film, packaged in a 704x480 frame with slim black borders on all 4 sides to display a 1.33333:1 image (I can see those borders on a 4:3 CRT if I set my player to zoom out slightly, and on HDTV when I disable overscan).

    Therefore, dear reader, I'd say 704x480 is a more likely encoder format for 4:3 originals. It's what I normally use, when I;m not in too much of a rush to reset my encoders' defaults. Maybe it depends on what various encoders do with 4:3. Take it from there.
    Last edited by sanlyn; 25th Mar 2014 at 11:59.
    Quote Quote  
  23. Originally Posted by 2Bdecided View Post
    It says that, in the absence of some extension I've forgotten the name of, the full frame is 4x3
    It's the Sequence Display Extension. I've only ever seen that used on commercial DVDs to define a pan-and-scan frame. The DVD is flagged as 4:3 and the Sequence Display Extension indicates that 4:3 image is contained in a 540x480 sub-frame. If you do the calculations you'll see that makes the full 720x480 frame exactly 16:9.

    Originally Posted by 2Bdecided View Post
    That MPEG-2 spec is clearly wrong
    How can the spec be wrong? The spec is the spec. Just because it's different from another spec doesn't make it wrong, only different. Every DVD and Blu-ray player I've tested (granted, only about a dozen) scales the entire 720x480 frame when upscaling to 1280x720 or 1920x1080 HDMI output. On the other hand the ones I've checked (only a few) follow rec.601 when putting out s-video or composite. So the players themselves are schizophrenic, following the MPEG spec for digital output, the rec.601 spec for analog output.

    http://www.comp.nus.edu.sg/~cs5248/l03/IEC-13818-2_Specs.pdf

    Originally Posted by 2Bdecided View Post
    because for nearly a decade after it was written there was no equipment that could achieve both these things, due to fixed 13.5MHz sampling rate and conventionally calibrated monitors.
    Rec.601 may have been the most common method of digitizing analog video but analog video wasn't the only source for DVDs.

    Originally Posted by 2Bdecided View Post
    If you encode 704x480 there's no contradiction or confusion, and no black bars either. It's the best choice for 4x3 DVD. I've no idea if this is a legal size for BluRay though.
    704x480/576 on Blu-ray media isn't supported by the Blu-ray spec. Though I assume they can handle it on DVD.
    Last edited by jagabo; 5th Mar 2013 at 10:15.
    Quote Quote  
  24. Member 2Bdecided's Avatar
    Join Date
    Nov 2007
    Location
    United Kingdom
    Search Comp PM
    Originally Posted by jagabo View Post
    How can the spec be wrong?
    A spec defines industry practice. If no one in the industry follows it, it's wrong.

    Did you know the colour subcarrier frequencies quoted in ITU Rec. BT.470 are wrong for some of the more obscure TV systems? I know they are wrong because (a) they were not the ones used in those systems in the real world, and (b) the real colour subcarrier frequency is related to the line frequency, whereas the one quoted in the spec is not.

    Where specs are obviously wrong (i.e. if you follow them, the system does not work) every one ignores them. Where specs are more subtly wrong, only smart people ignore them, and you can end up with a bit of a mess. This is one of those cases.

    The relevant threads are all linked from this one...
    http://forum.doom9.org/showthread.php?t=162474

    The spec is the spec. Just because it's different from another spec doesn't make it wrong, only different. Every DVD and Blu-ray player I've tested (granted, only about a dozen) scales the entire 720x480 frame when upscaling to 1280x720 or 1920x1080 HDMI output. On the other hand the ones I've checked (only a few) follow rec.601 when putting out s-video or composite. So the players themselves are schizophrenic, following the MPEG spec for digital output, the rec.601 spec for analog output.
    Many PC players do the same. That is why 704 is a better choice than 720 for encoding - it comes out the same however you interpret it.

    Rec.601 may have been the most common method of digitizing analog video but analog video wasn't the only source for DVDs.
    - but an N*13.5MHz sampled DAC was the only way of getting video out of a DVD player (or other consumer digital video source) until HDMI was invented. So from 1995 to 2003 the only way to follow the MPEG spec (i.e. that 720x480 and 704x480 should both fill the exact same 4x3 space on the display) would have been to add a video scaler and throw away all the original pixels, replacing them with an interpolated version. Unsurprisingly, no one did this; they ignored the obviously incorrect spec and clocked the pixels out at 13.5MHz unchanged, meaning that 720 was wider than 704.

    704x480/576 on Blu-ray media isn't supported by the Blu-ray spec. Though I assume they can handle it on DVD.
    That is a shame, though not surprising: 1080p25 isn't properly supported either. They really didn't think these picture format issues through properly. Too busy rushing to market to fight a format war IIRC.

    Cheers,
    David.
    Last edited by 2Bdecided; 6th Mar 2013 at 06:00.
    Quote Quote  
  25. Banned
    Join Date
    Oct 2004
    Location
    New York, US
    Search Comp PM
    -30-
    Quote Quote  



Similar Threads

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