Fly Away to IVTC Land
[Megaupload links at end]
Taking another detour on this brief encoding stint, this time to the domain of standard definition "film." I qualify film because it's not necessarily film, but the footage is treated largely as if it were shot at 23.976 frames per second, just as film has traditionally been recorded (with NTSC).
Given the standard NTSC interlaced frame rate of 29.97 fps, a resampling method was needed, which wound up being 3:2 pulldown.
If everyone just soft telecined their DVD masters properly, we wouldn't be having this discussion. But never underestimate the determination of industry to make life difficult for its customers, whether through disrespect or ineptitude, and I say this with more than just the entertainment industry in mind.
My edition of THYME's debut album First 9uality came with a DVD containing the three PV's that they had released up to that point: Hello, forever we can make it!, and Fly Away. All of them were hard telecined, forcing me to commit more effort than just Force Film in DGIndex.
Fortunately for me, a straight-up hard telecine is also straight-forward to inverse-telecine with current AviSynth IVTC filters, with results being Good Enough to the extent that I wasn't compelled to second guess the field matching decisions. There was the occasional gotcha in each PV, which will be described below in turn.
All filter chains were based, in some way, off AnimeIVTC, although AnimeIVTC was not invoked directly. I only wanted the dependencies for a select few cases, so I pulled the relevant operations with some slight adjustments.
Since the PV's came off a VOB, the DGMPGDec package is required in all cases. DGIndex was used to cut and extract the audio, while MPEG2Source was used as the entry point into AviSynth.
Fly Away
Filters:
Incidentally, these are all tritical filters. The first three are found at the bottom of the first post of this thread.
The trickiest step in IVTC is field matching, performed by TFM. For hard telecined material, AnimeIVTC's highest precision setting uses the following line:
ht = i.tfm(slow=2,clip2=i.tdeint(2,edeint=i.nnedi(-2),emask=i.tmm(1)))
This is apparently the most accurate setting but also the "slowest." I believe that you have not encountered "slow" until you let TempGaussMC loose on 1080i video. Other than changing the variable names, I chaned to NNEDI2 and upped the default post-processing parameter from 6 to 7.
Post-decimation to 23.976 fps, some scene changes had noticeable blending, while others had none. The above is one such obvious example, where it looks like two similar frames have been stacked on top of each other. I tried lowering TFM's scene change threshold scthresh, but in the course of bumbling around somehow managed to discover the mtype parameter in TMM.
There was some residual combing afterwards, so I applied VinVerse to mop it up with good results. The final script:
source = MPEG2Source("flyaway.d2v", idct=5)
deinterlaced = source.tdeint(2,edeint=source.nnedi2(-2),emask=source.tmm(1,mtype=2))
matched = source.tfm(mode=1,slow=2,pp=7,scthresh=12,clip2=deinterlaced)
ivtced = matched.tdecimate().vinverse()
cropped = crop(ivtced,2,62,-6,-58)
return cropped
scthresh is in there, but it is the default value of 12.
I felt that at this point, things were Good Enough. I note that there was still some minor blending, detectable if you step through certain scenes where there is motion and transparent overlay. They're infrequent enough and of sufficiently short duration as to be immaterial when watching at speed.
The black bars were cropped off, but I wanted to trim as little of the actual video as possible. Since YV12 video can only be cropped (on all sides) by even numbers of pixels, I compromised by leaving thin strips of black in situations where cutting another two pixels would eat into the video proper.
The final resolution is an unusual 712x360, and x264 complained about the dimensions not being evenly divisible by 16, but I'm not concerned with issues of hardware player compatibility or extreme compressibility: the thing is going into an MKV container with FLAC audio and for the foreseeable future I doubt that anything other than a software player will be able to play it.
Other remarks:
Heavy use of blurring for artistic effect, at least I hope it's deliberate and not bad autofocus. Good for compressibility, but I don't see the point.
Lots of static images, also good for compressibility. I don't mind it, although I should have bumped up the number of reference frames for x264 though. As it stands, the H.264 stream is only slightly larger than the FLAC stream.
forever we can make it!
At about 19 seconds in, just before the band busts out, there is a brief flash of thyme's face as a transparent overlay. To get rid of the blending this caused, I lowered scthresh to 6 while keeping everything else the same. That's kind of kludgy because the scene does not technically change, and inserting kludges bothers me some, but again it's so short that there's not much value to be had in revisiting it.
This PV uses the full SD width, so only the top and bottom bars were cropped, leaving a resolution of 720x364. Not mod 16 once again. The video is fairly kinetic, and x264 demanded that I pay about 1.7 Mbps for a CRF of 18. Still, the fully muxed MKV is smaller than at least one AVI of the same PV, perhaps largely a function of the cropping.
Hello
Filters:
- TempGaussMC and friends
- Optional: GradFun2DBmod, GradFun2db and AddGrainC v1.5
After two fairly successful IVTC runs on the above PV's, I felt that maybe I could get away with using the same filter chain a third time. Unfortunately, third time's not the charm, because there is material use of transparent overlays, and they're all telecined themselves. The result is two telecined streams stacked on top of each other: double hard telecine.
At its highest precision DHT mode, AnimeIVTC does away with TIVTC and field matching. As far as I can tell, it deploys TempGaussMC to deinterlace up to 59.94 fps, followed by deblend and decimation. It's like a video form of a multirate resampling filter.
It turns out that deblend isn't necessary, and algorithmic selection decimators like TDecimate are a little too smart for their own good in this case. What I need is indeed a simple decimation (SelectEvery) after a pretty sophisticated interpolation (TempGaussMC), i.e. boring old resampling.
The problems you see with something like TDecimate are in those transparent moving sky paintings. Some travel slower than others, and it is the slowpokes that experience stuttering movement. That's the result of non-uniformly (i.e. intelligently) choosing which frames to decimate.
AnimeIVTC recommends only using the SelectEvery method if you are going from NTSC telecined to NTSC film. I'd think it would be possible to do NTSC-PAL conversions, although I suppose the conversion ratios aren't working to your favour. At any rate, I don't require nor want PAL.
If I started with Hello first, I'd have used this exclusively, even though it'd be overkill for the other two PV's. The only reason why I didn't was because I quickly recognized that Hello was the trickiest of the three, so I avoided it.
Having been stunned by the 0.05 fps performance of TempGaussMC on 1080i, I once again opted for a lossless rendering pass, this time at 59.94 fps since AnimeIVTC did not decimate until the very end. On SD content rendering speed averaged 3 fps, which is lighting fast in comparison.
Other remarks:
A vignetting effect has been applied throughout the video, and the resulting gradients frequently lead to banding. I've applied a debanding filter to gently remove some of the bands, but short of finding a de-vignetting filter I don't think they'll ever be entirely mopped up, so this filter chain has been stamped with the Good Enough seal of approval.
At 720x374, this is another full SD width PV, but a lot less kinetic than forever we can make it!. The result is a 1.3 Mbps average bitrate for CRF 18.
The script, post TempGaussMC:
import("H:\Program Files\AviSynth 2.5\plugins\GradFun2DBmod.v1.3.avsi")
ivtced = AviSource("hello_tgmc.avi").selectevery(5, 0, 2)
deband = gradfun2dbmod(ivtced, radius=3)
cropped = crop(deband, 0, 56, 0, -50)
return cropped
Megaupload Links
P.S.
You may have to give Media Player Classic a slightly kick when playing forever we can make it!. For some reason it delays the audio and then stops the video stream to allow the two to synch at the 15 second mark. A possible workaround is to skip forward one second. This seems to force MPC to synch the two streams immediately.
Creating an MKA with the FLAC file leads to the same stalling problem at 15 seconds in. An MKV with WAV muxed in is problem free. For whatever reason, something doesn't like this one FLAC file.