Making HD material more compressible

[AlonP]

Hi,

I have an hour and a half footage of my dad's birthday - there's lots of movement since ruskis+drinking=dancing and what not. Or at least they call it dancing... *shrugs*

At any rate, they want the video sent to their friends - so far a decent quality is achieved at ~8k bitrate. I'd like to make it much more compressible, without losing too much, and wuthout it taking more than 48 hours to encode(i7-950).

What filters/scripts would you guys suggest?

[Reel.Deel]

You can try STPresso: http://avisynth.nl/index.php/STPresso

Unfortunately for optimal results it's only recommended for resolutions up to 720p. I've never tried it with 1080p so I'm not sure how well it works.

[kuchikirukia]

spline36resize(1280,720)

[feisty2]

Blur(1).blur(1)...blur(1)

[creaothceann]

Increase encoding time. (preset=placebo) (https://trac.handbrake.fr/wiki/x264VideoSettings)

[BakaProxy]

Wow these are like one of the most useless answers I've seen to date on such a basic problem.

Either way I'd first try to use variable bitrate instead of contstant. Then if downscaling is an option it's probably the easiest way to compress your video more. If not try getting rid of as much temporal noise (like grain), I suggest taking a look at smdegrain, despite the name it doesn't only work on grain as well. And lastly if that fails take a look at spatial denoisers like knlmeans, dfttest, f3kdb and/or gradfun3 from the dither package, those will help compressibility at the expense of detail. Well lastly, but honestly a given, use a decent encoder like x264 or possibly even x265 for this scenario.

[johnmeyer]

Short answer: encode to MP4 H.264 using Handbrake.

Use either VBR or constant (just to confuse things, I'd recommend "constant quality" encoding, but VBR works pretty well too). Handbrake tutorials are a dime a dozen, so just use Google to find one. Over at the Vegas forum, many people have done tests comparing different ways to get the "best" quality at low bitrates (i.e., for small file sizes), and Handbrake seems to have emerged as the overwhelming favorite, at least on that forum. It sure beats the two H.264 encoders built into the "professional" version of Vegas.

While Google will turn up lots of tutorials, here are two links that take you to two Vegas forum discussions about this subject:

The "well known" Handbrake tutorial? (http://www.sonycreativesoftware.com/forums/showmessage.asp?forumid=4&messageid=893380)

handbrake tutorial (http://www.sonycreativesoftware.com/forums/showmessage.asp?forumid=4&messageid=842317)

[raffriff42]

STPresso seems worth a look. But in general, yes, downsizing + temporal filtering is the way to go. Downsize especially if this is footage from a typical camera you see these days, with lots of advertised "megapixels" but with optical and noise problems that make that high resolution useless. Downsizing in that case loses very little information. (EDIT in fact it filters out some sensor noise)

And yeah, Handbrake has a reputation (http://www.sonycreativesoftware.com/forums/showmessage.asp?messageid=861910)for being very bit-efficient for some reason.

[Reel.Deel]

Wow these are like one of the most useless answers I've seen to date on such a basic problem.


I don't think suggesting STPreso is a complete useless answer. Yeah I might of been vague but it did answer the OP's question (What filters/scripts would you guys suggest?). It's certainty more useful than "Blur(1).blur(1)...blur(1)" :D.

A while back I was encoding the 1st and 2nd season of "That '70s Show" (http://www.amazon.com/That-70s-Show-Season-Blu-ray/dp/B005X7HA58), it was shot on film so some scenes where quite grainy and temporally unstable. I experimented with STPresso and other things but in the end I decided to lightly denoise the 1080p video with SMDegrain, downscale to 720P and then use STPresso. The compression gain was a bit better than just denoising with SMDegrain and then downscaling to 720p. I also did a few test encodes with various x264 settings to see which settings to choose for optimal compression/quality.

----

Isn't handbrake just a frontend for x264 (and other encoders)? AFAIK Handbrake doesn't do anything special, x264 is where all the magic happens :p.

-----

That statement overlooks two things:

1. Handbrake encodes to many formats, not just h.264.

2. Much more important, while decoding h.264 always produces identical quality results (CPU usage can vary), regardless of the decoder, encoding to h.264 is completely and totally different from one encoder to the next. Some are really good, and some are actually quite awful.

So, with some encoders, the magic doesn't happen. Put another way, h.264 is not a guarantee to good quality.

Since Handbrake is open source, and since I haven't looked carefully at its pedigree, I don't know where the h.264 encoding was developed, and whether it is identical to what can be found in, for instance, MeGUI. That happens to be what I use, and it also does a really good job with low-bitrate encodes. I use MeGUI because of its close coupling with AVISynth, but I've seen comparisons with Handbrake, and they seem to produce pretty similar results.

1) Yeah I know, that's why I said Handbrake is just a frontend for x264 and other encoders (x265, Xvid, etc).

2) Yup, specs require all H.264 decoders to be identical. Also I'm not talking about other encoders, I'm talking about x264 (http://www.videolan.org/developers/x264.html), the encoder that Handbrake uses.

x264 is very popular and is considered to be the best H.264 encoder by some. There's no mystery why so many encoding apps (https://en.wikipedia.org/wiki/X264#x264_frontends) use it (Handbrake and MeGui included). I've often see people giving high praises to such apps but fail to recognize the actual software behind the scenes that deserves the real credit. x264 is where all the magic happens. :)

[johnmeyer]

Isn't handbrake just a frontend for x264 (and other encoders)? AFAIK Handbrake doesn't do anything special, x264 is where all the magic happens :p.That statement overlooks two things:

1. Handbrake encodes to many formats, not just h.264.

2. Much more important, while decoding h.264 always produces identical quality results (CPU usage can vary), regardless of the decoder, encoding to h.264 is completely and totally different from one encoder to the next. Some are really good, and some are actually quite awful.

So, with some encoders, the magic doesn't happen. Put another way, h.264 is not a guarantee to good quality.

Since Handbrake is open source, and since I haven't looked carefully at its pedigree, I don't know where the h.264 encoding was developed, and whether it is identical to what can be found in, for instance, MeGUI. That happens to be what I use, and it also does a really good job with low-bitrate encodes. I use MeGUI because of its close coupling with AVISynth, but I've seen comparisons with Handbrake, and they seem to produce pretty similar results.

[MysteryX]

1. Use KNLMeans (http://forum.doom9.org/showthread.php?t=171379) to reduce noise
2. Use x264's preset veryslow or placebo
3. Unless you need a specific file size, use constant quality, it does a great job.
4. (optional) Resize to 720p as suggested and compare the quality/size difference

[creaothceann]

3. Unless you need a specific file size, use constant quality, it does a great job.

Isn't CRF better?

[Groucho2004]

Isn't CRF better?
I'm quite certain that using CRF was implied when he suggested constant quality.

[feisty2]

Constant quality = qp != crf

[vivan]

qp is constant quantizer ("quantization parameter").
crf is constant ratefactor which is an encoder's idea of quality.
As such crf is sometimes referred as "constant quality". qp? Almost never, except inferior encoders like xvid that lack crf.

[Groucho2004]

Constant quality = qp != crf
Have a look here (https://en.wikibooks.org/wiki/MeGUI/x264_Settings)

crf

Default: Not Set

The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain 'quality'. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. It is not extremely exact, but reasonably close (and will average out to be accurate over a large number of videos).

[feisty2]

Qp= constant OBJECTIVE quality
Crf= constant SUBJECT quality
I put my trust on objective stuff, not subjective

[Groucho2004]

Qp= constant OBJECTIVE quality
Crf= constant SUBJECT quality
I put my trust on objective stuff, not subjective
Almost all image, video and audio compression algorithms are based on models of human perception. I don't care how good the psnr or ssim values are, I want it to look good.

[feisty2]

The only way to keep it looking good is, pick lossless algorithms instead of lossy ones

[creaothceann]

The only way to keep it looking good is, pick lossless algorithms instead of lossy ones

So crf=1 looks bad to you?

[Groucho2004]

The only way to keep it looking good is, pick lossless algorithms instead of lossy ones
Sure. Why did I not think of that? Silly me.

[feisty2]

Crf1 looks crc32wise bad to me (bit exact is a must cuz it's already that big)

[Groucho2004]

Crf1 looks crc32wise bad to me
It should look bad "crc32wise".

Also, may I add "crf1 looks crc32wise bad to me" to my list of funny phrases for future use?

[feisty2]

Not funny, do some tests
Crf1 is sometimes larger than qp0(lossless)

[Groucho2004]

Not funny, do some tests
Crf1 is sometimes larger than qp0(lossless)
I was not disagreeing with you.

[feisty2]

http://x265.readthedocs.org/en/default/lossless.html#lossless-encoding
Funny stuff
"It is not unusual for bitrate to drop as you increase lossless coding. Having “perfectly coded” reference blocks reduces residual in later frames. It is quite possible for a near-lossless encode to spend more bits than a lossless encode."

[Sharc]

@AlonP
Is your clip interlaced or progressive?
If it's interlaced, don't forget to deinterlace before applying any resizing filters. On the other hand, if it is interlaced you may want to preserve the temporal resolution (motion smoothness) of the dancing+drinking ruskis, hence encode it as interlaced or use a decent bobber :D.

[colours]

Qp= constant OBJECTIVE quality
Crf= constant SUBJECT quality
I put my trust on objective stuff, not subjective

Your post is objectively wrong. The main difference between constant QP and constant rate factor (in x264) is the usage of qcomp and MB tree; these control quantisers for individual macroblocks by scaling them in proportion to how often they're used, which is a net saving on bitrate for the same objective quality. It's just that everyone only ever mentions how they affect subjective quality because (i) they do affect subjective quality more and (ii) nobody cares about objective quality according to a metric that doesn't closely match human visual perception. (Other than the people who write video codecs. Sup On2.)

Just to prove you wrong, I spent a couple of minutes testing my hypothesis. Source is 1280×720, 1000 frames long; target bitrate is 1200 kbit/s.

x264 [info]: PSNR Mean Y:49.004 U:51.201 V:50.475 Avg:49.506 Global:49.123 kb/s:1212.79
x264 [info]: PSNR Mean Y:48.803 U:50.955 V:50.140 Avg:49.286 Global:48.783 kb/s:1207.85
x264 [info]: PSNR Mean Y:47.805 U:50.158 V:49.160 Avg:48.310 Global:48.157 kb/s:1217.12

--tune psnr disables AQ and all other psychovisual optimisations, so this is effectively equivalent to comparing CQP and CRF, and it's clear that CRF is better when optimising for PSNR. I don't think the results will be very different with SSIM, but I can't be bothered to test.

[feisty2]

well, I don't really know much about encoders cuz, I don't really use anything other than --qp 0 -- preset placebo, I'm looking for, bit exact (I make mastertapes, not bluray or dvd)
but that just gets my curiosity revved up, I'll do some investigation about it

[johnmeyer]

The only way to keep it looking good is, pick lossless algorithms instead of lossy onesWell, I guess I'd better give up watching satellite or cable TV. And I definitely better never again watch a DVD or Blu-Ray. And, I'll throw out all my video cameras as well.

Actually, I can't think of one single commercial or consumer source of video that uses lossless compression (e.g., HuffYUV, Lagarith, etc.).

Even when generating intermediates in a long video editing workflow, lossy compression can still produce almost perfect results. For instance, the people at Cineform made quite a nice living for almost a decade (until they sold the company to GoPro) selling $1,000 lossy intermediate compression codecs that held up to multiple generations of re-compression, and which were virtually indistinguishable from the original.

In the end, this is about how the result looks, not about the internal math. There are lots of tools that can produce great-looking results without consuming an entire hard drive, and without requiring RAID to keep up with the playback data demands.

[creaothceann]

Is your clip interlaced or progressive? If it's interlaced, don't forget to deinterlace before applying any resizing filters.

Resizing only horizontally would be OK though.

[feisty2]

@johnmeyer
the rule is simple: you get to make some lossy files from a lossless file however you want, however you like, but you can't make a lossless file out of any lossy file
lossless = possibility for the future
besides, I would find something less valuable if it's somehow damaged (lossy), even if it's damaged just a little bit

[Sharc]

Well, I would strongly assume that the file which comes out of his videocam is already compressed, i.e. lossy.

[johnmeyer]

... lossless = possibility for the future
besides, I would find something less valuable if it's somehow damaged (lossy), even if it's damaged just a little bitI fully understand the purity of your argument, and cannot disagree with your science or math.

However, I am an engineer, not a scientist, and not a mathematician. As an engineer, I know that the real world is populated with constraints. I already mentioned some of the consequences of deciding to use workflows which employ either uncompressed or lossless compression. The question at hand is not whether there are differences between the original and the results of various alternative schemes for re-encoding the results of some set of editing actions, but instead the question is: does it matter?

Obviously it matters to you, so you use lossless compression. Fair enough. However, to people under deadlines, with finite budgets for equipment, and dozens of projects to finish in order to earn a living, tradeoffs are required, and that's what the OP (if we can, once again, try to keep things on track) was asking about, to whit: "making HD material more compressible."

[AlonP]

I would like to thank everybody - So ummm, errr, Thanks... Everybody :).

The video that was shot with the note 2 indeed could probably be resized without much loss of detail.Yet most of the video is shot with Canon EOS 700D - which is pretty decent.

I could downscale to 720p. Indeed, the only person who will see it is my parents' ruski friends in Moscow - for whom it is being encoded to begin with, and they would not really notice the difference, I suppose.

Yet, I feel it is... Not to be done. If you have footage which is 1080p... And you downscale it... To me... It's like... It's a loss which can't be regained...

Heavy filtering is a no-no, yet some light filtering, to make it more managable... Is a nice thing to do... I often encode Anime, and there Often there is no visible difference between an original frame - which say takes 1.4mb, and one which is filtered, which say takes 1.1mb. And so, I figure a filtration can be done which wouldn't realllly be noticable, yet would help reduce bitrate by perhaps 20-30%, In a way the same... "feelings" of aesthetics which prevent me from doing 1080p --> 720p also prevent me from encoding something before it has been... Mmm... "cleaned up", and prepared for a more compressible state of being.

@AlonP
Is your clip interlaced or progressive?
If it's interlaced, don't forget to deinterlace before applying any resizing filters. On the other hand, if it is interlaced you may want to preserve the temporal resolution (motion smoothness) of the dancing+drinking ruskis, hence encode it as interlaced or use a decent bobber :D.

It is progressive.




And again... Thank you guys ;). And girls.

[MysteryX]

KNLMeans doesn't lose much details, and it actually makes the source material look better because there's always some noise in it. It does make a considerable difference on encoding as there is less noise to encode, and thus, more of the bits go into storing real details. I use this when converting 1080p camera files into a format that is more space-efficient:
KNLMeansCL(D=2, A=1, h=1, device_type="GPU")
Try with either 1 or 2 for 'h' which is strength.

I agree with not wanting to resize 1080p to 720p; I probably wouldn't do it.

You don't need to know the difference between QP and CRF. I'd use x264.exe with CRF somewhere between 18 and 22, and preset 'veryslow'. Placebo would be even better but would take twice longer; whether it's worth the extra time is up to you.

As for variable bitrate, all it does is vary the CRF value for each frame based on its complexity in order to maintain a somewhat stable bitrate. At the end of the day, each frame still gets encoded with a fixed quality, but when using double-pass VBR, much more work is done to determine which quality value to use for each frame. That time is better spent in encoding with a higher quality preset. Unless you have a fixed-size storage such as a DVD, or unless you need stable bitrate such as for online streaming.

[creaothceann]

Well, then... try reducing temporal noise, use x264 ("crf" 16 mostly looks pretty identical to the source to me, increase from there), use a slow x264 "preset" when you're done with testing and encode the final video stream. Also encode the audio with AAC or MP3, test various quality settings.

Avisynth's spline resizers might retain enough detail for you when downscaling to 720p?

[wonkey_monkey]

Yet, I feel it is... Not to be done. If you have footage which is 1080p... And you downscale it... To me... It's like... It's a loss which can't be regained...

As is compressing it, reducing noise (some real detail is going to be lost as well), etc.

[AlonP]

Thanks a lot everybody, I am currently outputting to lagarith lossless, at 1.8fps. 130,000frames in total. Hopefully it'll finish without a glitch. I am using the script below:

SetMTMode(3)
AviSource("2. Connect and Filter.avi")
Trim(1,20809)++Trim(22211,23429)++Trim(24066,56999)++Trim(65106,140126)
SetMTMode(2)
Spresso(4,24,2).STpresso(4,24,4,12,3,49,1)
SMDegrain(tr=4,thSAD=400,contrasharp=true,refinemotion=false,lsb=true,chroma=false,plane=0,pel=1,prefilter=2)
VagueDenoiser(threshold=0.4, method=1, nsteps=5, chromaT=1.5,wiener=true,wavelet=2)

I've compared .png images of the output of this, and to be honest I did not see that much of a size reduction, however I did see somewhat more blurryness in some parts, tho it's not really that noticable and in most places it's not seen at all.

Thanks again everybody!

Edit:
FPS dropped to 0.8 lol. I suppose ~35 hours it is...
Edi2:
Aaaand VDub crashed *chuckles*. Rerunning with VagueDenoiser disabled. Runs a bit faster. Perhaps it wont' crush now, and if it doesn't I'll just do vaguedenoiser on the next lagarith pass. 1400frames done, pace at ~1.5fps, so far so good.
Edit3: And crashed again. Hmmm. I'll try and switch SetMtModes up. Perhaps that'll help.

[creaothceann]

I did not see that much of a size reduction

Well yeah, when you output to lossless...

I am currently outputting to lagarith lossless

[Groucho2004]

Edit3: And crashed again. Hmmm. I'll try and switch SetMtModes up. Perhaps that'll help.
What CPU is this running on?

Edit: If it as 8 logical cores, try "SetMTMode(3, 4)" as the first MT statement. Play with SetMemoryMax(), start with ~700, go up to 1500.

[AlonP]

What CPU is this running on?

Edit: If it as 8 logical cores, try "SetMTMode(3, 4)" as the first MT statement. Play with SetMemoryMax(), start with ~700, go up to 1500.

Thus far the farthest I got is with:

SetMTMode(2)
AviSource("2. Connect and Filter.avi")
SetMTMode(4)
Trim(1,20809)++Trim(22211,23429)++Trim(24066,56999)++Trim(65106,140126)
Spresso(4,24,2).STpresso(4,24,4,12,3,49,1)
SMDegrain(tr=4,thSAD=400,contrasharp=true,refinemotion=false,lsb=true,chroma=false,plane=0,pel=1,prefilter=2)

i7-950 cpu

Gonna go sleep now, will try to playt more with setmtmode later ;). setmemorymax tho crashes it immidiately, if it's 512, maybe IU need more... When vdub is running it takes 900mbram or so

[AzraelNewtype]

Well yeah, when you output to lossless...

He's comparing file sizes of png captures of frames, not the output.

AlonP, lagarith isn't really the fastest pony at the lossless rodeo. You may want to look into x264's lossless, or ut video. Either will do you better at lossless encode time and then decode for final output time.

[Groucho2004]

Thus far the farthest I got is with:

SetMTMode(2)
AviSource("2. Connect and Filter.avi")
SetMTMode(4)
Trim(1,20809)++Trim(22211,23429)++Trim(24066,56999)++Trim(65106,140126)
Spresso(4,24,2).STpresso(4,24,4,12,3,49,1)
SMDegrain(tr=4,thSAD=400,contrasharp=true,refinemotion=false,lsb=true,chroma=false,plane=0,pel=1,prefilter=2)

i7-950 cpu

Gonna go sleep now, will try to playt more with setmtmode later ;). setmemorymax tho crashes it immidiately, if it's 512, maybe IU need more... When vdub is running it takes 900mbram or so
Ok. Your CPU has 8 logical cores which means that the first SetMTMode() statement in your script is allocating 8 threads. The more threads, the more memory will be necessary.

I suggest to start with this script:
SetMemoryMax(1024)
SetMTMode(5, 4) #4 threads
AviSource("2. Connect and Filter.avi")
SetMTMode(2)
Trim(1,20809)++Trim(22211,23429)++Trim(24066,56999)++Trim(65106,140126)
Spresso(4,24,2).STpresso(4,24,4,12,3,49,1)
SMDegrain(tr=4,thSAD=400,contrasharp=true,refinemotion=false,lsb=true,chroma=false,plane=0,pel=1,prefilter=2)


Use AVSMeter (http://forum.doom9.org/showthread.php?t=165528) to observe the memory requirement and speed of your script while you increase the number of threads and/or the value for SetMemoryMax().

If you are on a 64 Bit OS, Avisynth can use up to 4 GB or memory instead of 2 GB. However, the application calling Avisynth (in your case VDub) has to be "large address aware". I don't know if that is the case for VirtualDub, maybe someone knows. There is also a patch utility to make a program "LAA".

[colours]

I just want to add that it looks like all the plugins you're using in your script have 64-bit binaries available and you should try out 64-bit AVS/AVS+ in case Groucho2004's suggestions don't help.

[Groucho2004]

I just want to add that it looks like all the plugins you're using in your script have 64-bit binaries available and you should try out 64-bit AVS/AVS+ in case Groucho2004's suggestions don't help.
I'd say with the amount of heavy filtering he's doing he needs a multi-threaded Avisynth workflow. From my experience and from what I've read here, AVS+ is not stable enough in MT mode. Not that SEt's AVS MT is rock solid but still a better choice than AVS+ MT in its current state.
Being able to use 4 GB with 32 bit Avisynth should be enough for all filtering needs methinks...

[sneaker_ger]

the application calling Avisynth (in your case VDub) has to be "large address aware". I don't know if that is the case for VirtualDub, maybe someone knows.
The official version is not. I made a patched version some time ago:
https://www.mediafire.com/?5wdk1o6wm7c94zz

[AlonP]

Just came back from an Eckhart Tolle seminar in London. WAs fun. Gonna look into all of that over this week. Wow... So many suggestions ;). Awesome ;). Thanks you guys! ;).
Edit1:

Ok, so after many attempts, this worked out:

SetMemoryMax(1024)
#SetMTMode(5,4)
AviSource("2. Connect and Filter.avi")
SetMTMode(3,4)
Trim(1,20809)++Trim(22211,23429)++Trim(24066,56999)++Trim(65106,140126)
Spresso(4,24,2).STpresso(4,24,4,12,3,49,1)
#SMDegrain(tr=4,thSAD=400,contrasharp=true,refinemotion=false,lsb=true,chroma=false,plane=0,pel=1,prefilter=2)
#VagueDenoiser(threshold=0.4, method=1, nsteps=5, chromaT=1.5,wiener=true,wavelet=2)

In the first setMTMode line I tried various things. I tried to do it 2,4 and 3,4 and 5,4 - while also trying various ones on the second line. The only way it worked was when I just disabled the first setmtmode. It never crashed immidiately. Various modes took more or less time to crash. One of those lasted more than an hour before crashing.

Anyway, I still need to have fun with SMDegrain and Vague denoiser. I have downloaded the "large address aware" patched virtual dub posted by sneaker_ger. I will now start messing with it. my first attempt will be this:

SetMemoryMax(2048)
SetMTMode(3,6)
AviSource("3. Denoising and trimming.avi")
SetMTMode(3,6)
SMDegrain(tr=4,thSAD=400,contrasharp=true,refinemotion=false,lsb=true,chroma=false,plane=0,pel=1,prefilter=2)
VagueDenoiser(threshold=0.4, method=1, nsteps=5, chromaT=1.5,wiener=true,wavelet=2)

Thus far it gives me 2.2fps. which is really nice. 5minutes in, no crash yet ;).

Edit2:

Aaaand the above script crashed after about an hour and a half. Next script I will be trying:

SetMemoryMax(2048)
SetMTMode(3,4)
AviSource("3. Denoising and trimming.avi")
SMDegrain(tr=4,thSAD=400,contrasharp=true,refinemotion=false,lsb=true,chroma=false,plane=0,pel=1,prefilter=2)
VagueDenoiser(threshold=0.4, method=1, nsteps=5, chromaT=1.5,wiener=true,wavelet=2)

Edit3:

Aaand the above crashed after like 5 minutes. Now trying this one:

SetMemoryMax(2048)
AviSource("3. Denoising and trimming.avi")
SetMTMode(3)
SMDegrain(tr=4,thSAD=400,contrasharp=true,refinemotion=false,lsb=true,chroma=false,plane=0,pel=1,prefilter=2)
VagueDenoiser(threshold=0.4, method=1, nsteps=5, chromaT=1.5,wiener=true,wavelet=2)

Runs at 1fps. Yet if it doesn't crash... I should try ffmpegsource2 instead of avisource maybe. Perhaps avisource doesn't do well with setmtmode. Hmmm. The smarter thing would be to use that "meter" program... But I'm barely home, so I rather just go with brute force.

Edit4:

So after 37hours of encoding, it finished. Seems like Using SetMTMode before avisource crashes the script. I will be trying to substitute it with ffmpegsource2 /lmash. we'll see what's up. Will edit in another few days.