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)
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 25 of 25
Thread
-
Last edited by VideoFanatic; 2nd Mar 2013 at 09:21.
-
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. -
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.
-
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()
-
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.
-
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()
-
Last edited by sanlyn; 25th Mar 2014 at 11:57.
-
The screen moves up and down due to old VHS equipment. Can anyone help me with this encoding speed problem?
-
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)
-
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()
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:
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)
Last edited by jagabo; 2nd Mar 2013 at 12:09.
-
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.
-
Last edited by jagabo; 2nd Mar 2013 at 13:09.
-
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.
-
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.
-
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?
-
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.
-
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)
But I'm using a different encoder.Last edited by sanlyn; 25th Mar 2014 at 11:58.
-
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.
-
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.
-
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.
Cheers,
David. -
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.
-
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.
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
Rec.601 may have been the most common method of digitizing analog video but analog video wasn't the only source for DVDs.
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.
-
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.
Rec.601 may have been the most common method of digitizing analog video but analog video wasn't the only source for DVDs.
704x480/576 on Blu-ray media isn't supported by the Blu-ray spec. Though I assume they can handle it on DVD.
Cheers,
David.Last edited by 2Bdecided; 6th Mar 2013 at 06:00.
Similar Threads
-
Avisynth MDegrain very slow
By Dominik2000 in forum Video ConversionReplies: 0Last Post: 4th Feb 2013, 06:24 -
Avisynth - Stack 4 Videos But Too Slow - Help!
By controlalt in forum EditingReplies: 10Last Post: 14th Mar 2011, 09:36 -
Cannot encode my avisynth file
By V-Spatial in forum Newbie / General discussionsReplies: 6Last Post: 25th Feb 2010, 15:13 -
can't install Avisynth due to the devil.dll
By cemman in forum Newbie / General discussionsReplies: 6Last Post: 2nd Aug 2009, 06:18 -
How to encode an xvid file to another xvid and prevent video blocking?
By BlooderButcher in forum Video ConversionReplies: 5Last Post: 21st Nov 2008, 17:03