DepanStabilize a DV PAL 16:9 BFF interlaced clip ?

[halsboss]

Hi, is this the latest correct way to stabilize a camcorder DV PAL 16:9 BFF interlaced clip using Fizick's plugins?


AssumeBFF()
SeparateFields()
source = LAST # assume SeparateFields() has been done
vectors = source.MVAnalyse(isb = false)
globalmotion = source.MVDepan(vectors, pixaspect=1.094, thSCD1=400) # not too sure about pixaspect=1.094 ?
DepanStabilize(source, data=globalmotion, cutoff=2.0, mirror=15, pixaspect=1.094)
Weave()


Thanks.

edit: Oh well, while I'm asking... I've forgotten how (if I ever knew) to use LimitedSharpenFaster on interlaced material, without deinterlacing if possible... is it this ?

SeparateFields()
LimitedSharpenFaster(smode=4, strength=115)
Weave()

Feel free to point out it's dumb and fruitless.

[zambelli]

No, what you need to do is bob the material to 50p first, then stabilize and sharpen it, and then weave it back to 25i. So it'd be something like this:

AssumeBFF()
MCBob() # or Tdeint(mode=1), or whatever else you prefer
source = LAST # assume SeparateFields() has been done
vectors = source.MVAnalyse(isb = false)
globalmotion = source.MVDepan(vectors, pixaspect=1.4545, thSCD1=400)
DepanStabilize(source, data=globalmotion, cutoff=2.0, mirror=15, pixaspect=1.4545)
LimitedSharpenFaster(smode=4, strength=115)
AssumeBFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()

Note: I didn't correct any of your Depan and LSF settings, since I'm not familiar with your content.

16:9 PAL pixel aspect ratio is 1.4545.

[halsboss]

Thankyou Zambelli.

I guess TDEINT it is, since the 720x576 1 hr clip already takes ages to clean/convert with HC as it is - about 2fps with just a couple of simple FFT filters ... Nice info on the aspect ratio.

[Boulder]

Using YADIF for bobbing would make things even faster ;)

[halsboss]

Thanks ! I managed to get down to 1 fps using the following script into HC :)


AviSource("D:\HDTV\DV\chop-dv.avi", audio=false)
AssumeFPS(25)
AssumeBFF()
FFT3DFilter(sigma=2.5, plane=4, sharpen=1.0, degrid=1.0, interlaced=TRUE) # luma and chroma together
AssumeBFF()
Yadif(mode=1,order=0) # mode=0=deinterlace mode=1=doubleframerate, order=0=BFF order=1=TFF
source = LAST
vectors = source.MVAnalyse(isb = false)
globalmotion = source.MVDepan(vectors, pixaspect=1.4545, thSCD1=400)
DepanStabilize(source, data=globalmotion, cutoff=2.0, mirror=15, pixaspect=1.4545)
AssumeBFF()
Converttoyv12() # moved per zambelli post below
SeparateFields()
SelectEvery(4,0,3)
Weave()
AssumeBFF()
#Converttoyv12() # move this up a bit per zambelli post below
SetPlanarLegacyAlignment(True)


DV Input (10.5 Mb) http://rapidshare.com/files/54900453/chop-dv.avi.html
MPEG2 Result (3.5 Mb) http://rapidshare.com/files/54901014/chop-dv.mpv

Any suggestions on proper MVDepan and DepanStabilize settings to lessen the "mirror effect" at top and side ? This is probably around the mark or maybe on the max-movement side as a sample, later there's a lot of standing and panning. (2007 Adelaide Royal Show)

[Boulder]

If you plan to do a 2-pass encode and have lots of HD space to spare, consider encoding first to a lossless format such as HuffYUV or Lagarith and then encode with HC.

Installing Cedocida for DV decoding (and enabling interlaced MPEG-2 YV12 output in its settings) should also provide a performance boost.

One other thing, if you convert the colorspace, do it before the reinterlacing part.

[halsboss]

Thanks Boulder ... is there a significant advantage to doing a 2-pass vs a high bitrate single pass ? I wasn't planning a 2 pass HC encode since it's a camcorder whilst walking type home movie :) ...

*INFILE D:\HDTV\DV\chop-dv-CQ3.avs
*OUTFILE D:\HDTV\DV\chop-dv.mpv
*INTERLACED
*BFF
*LOGFILE D:\HDTV\DV\chop-dv-HC-CQ3.log
*PROFILE BEST
*ASPECT 16:9
*BITRATE 9200
*MAXBITRATE 9400
*LASTIFRAME
*AUTOGOP
*PULLDOWN
*CLOSEDGOPS
*DC_PREC 9
*LUMGAIN 3
*CQ_MAXBITRATE 3
*MATRIX MPEG

I have the latest ffdshow codec ... would Cedocida for DV decoding be much of an improvement in speed or quality do you think ?

Happy to test these, just wanted your thoughts.

And the convert to YV12 for input to HC would presumably become

AssumeBFF()
Converttoyv12()
SeparateFields()
SelectEvery(4,0,3)
Weave()
AssumeBFF()

I suspect but do not know that ffdshow is serving YV12 from AVIsource anyway ?

[Boulder]

ffdshow should be fine, and it probably outputs YV12 already if it is enabled in the settings. You can check it using a script that only loads the source + has the line Info() in it. I don't know which codec is faster though. One thing that makes encoding slower is that there's probably constant re-encodings of the GOPs going on (due to VBV buffer compliancy and to keep the max bitrate). The next HC version should make these situations faster.

By the way, why do you use AssumeFPS(25) and the use pulldown in HC?

I would do a constant quant encode with that high bitrates. I'd also use DC precision of 10 bits.

[zambelli]

I have the latest ffdshow codec ... would Cedocida for DV decoding be much of an improvement in speed or quality do you think ?
Yes, definitely use Cedocida for PAL DV - it will give you pure 4:2:0 (YV12) without any interpolation.


AssumeBFF()
Converttoyv12()
SeparateFields()
SelectEvery(4,0,3)
Weave()
AssumeBFF()

Yes, it's very important that you do ConvertToYV12() before you make the video interlaced. In your previous version of the script you would've actually broken chroma by doing a progressive conversion on an interlaced video.

[halsboss]

By the way, why do you use AssumeFPS(25) and the use pulldown in HC?

I would do a constant quant encode with that high bitrates. I'd also use DC precision of 10 bits.
10 bits it is then ... I'd just reduced it for this script naively hoping it'd speed things up :) A CQ you say ? I'll give it a try after checking the doco on how ... I noticed duing the encode that the 3 "quant" numbers in the HC window jumped all over the place, a fair amount of the time in the 8-11 range (still looks OK) even though the bit rate was rather high but never much "maxed out" and hovered in the 7000-8000 range (strange since the .INI says to max it out and the CQ was raised significantly a fair bit of the time)... and I don't understand what that really means (I'd assumed the target quant was set at 3 by the .INI ? From the HC doco

*CQ_MAXBITRATE
parameter quantization type real
Status not required
Default -
Example *CQ_MAXBITRATE 5.8
This command orders the encoder to do a 1-pass with a constant quantization factor.
If the actual bitrate overshoots the maximum bitrate set by the *MAXBITRATE command the
quantizer is temporally raised. Output will be DVD-compliant.

*BITRATE
parameter bitrate type integer
Status required
Default -
Example *BITRATE 3250
This command specifies the average bitrate per second in kbits/s. (1 kbit = 1000 bit)

*PULLDOWN
parameter - type -
Status not required
Default -
Example *PULLDOWN
This command sets pulldown flags for 23.976 → 29.97 pulldown.
Interlaced will be turned off, if your source is interlaced, please de-interlace it first.
If the source isn't 23.976 fps this setting will be ignored.


Hmm, I'd thought pulldown was ignored for PAL input so I didn't worry about it (.AVS script is generated from a generic .BAT and that bit was not subject to an IF test). I'll have to go back and check the doco I guess.

Yes, it's very important that you do ConvertToYV12() before you make the video interlaced. In your previous version of the script you would've actually broken chroma by doing a progressive conversion on an interlaced video.

Yikes, I'd been doing the wrong thing then whenever I deinterlaced and mucked around with filters and reinterlaced (not often, usually left it interlaced and did FFT3d whilst interlaced, on the principle "less is better"). Off to update the .BAT file, then.

[Boulder]

The encoder doesn't always reach the maximum even in CQ mode, this is due to maintaining the VBV buffer within DVD specs. You are seeing those high figures because HC needs to raise the quants to keep the maximum bitrate and avoid any VBV buffer issues (which would result in playback problems).

Yes, you don't need to worry about pulldown in your case.

You might want to tweak the CQ_PFACTOR and CQ_BFACTOR parameters. I'm not sure if it's good to use the exact same quant for all frame types. I've been using PFACTOR 1.05 and BFACTOR 1.6 for my DV encodes in CQ mode. Sometimes I've done an intermediate lossless file and encoded in 2-pass mode with same max and avg bitrate values and bias 100. If you want to use LUMGAIN, that is the only way to go as it is not used in CQ mode.

[halsboss]

Sometimes I've done an intermediate lossless file and encoded in 2-pass mode with same max and avg bitrate values and bias 100. If you want to use LUMGAIN, that is the only way to go as it is not used in CQ mode.

OK. Thanks for your advice. Just wondering what the advantage of a lossless intermediate file going into HC is vs avisynth directly into HC ? I've never done a 2-pass, so I'd guess at avisynth not having to process/filter twice (once for each pass).

[Boulder]

If the script is slow and you do multiple passes, encoding first to a lossless format and then using it to encode to final format should be faster than feeding the slow script and encoding.

Also there have been occasional problems with complex scripts and different encoders. Using an intermediate file will help avoid these problems.