Is there any way to speed this up?

[RedDwarf1]

I have a video which has two sections where the main part has no black border on the sides but the second section has a small black border on the left. I would like to crop the video so as not to do unnecessary cropping. I have tried a script but it seems a lot slower than doing it all cropped the same.

Here is the important section as I have it at the moment. What I need are recommendations on any speed ups to the script. Does the way it works at the moment resize twice? Or does it only resize while in the first range and not for the 2nd part until that is reached?

part1=trim(deinterlaced_video,0,58532)
part2=trim(deinterlaced_video,58533,0)

resize1=BilinearResize(part1,640,352,0,2,-0,-2)
resize2=BilinearResize(part2,640,352,3,2,-0,-2)
resize=resize1+resize2

[burro08]

Virtual dub should work ok and quick

[foxyshadis]

That is as fast as possible, your first assumption is correct: It only resizes once on each range. It'll also be blindingly fast, if anything's slowing it down it'll be the rest of your script.

[RedDwarf1]

Okay thanks.

I have just checked the VirtualDubMod job list and a previous encode using the same basic script except for the part listed above. The videos were almost identical length, the one I did last night being only 13 seconds longer. Yet the encode times were very different. The first pass was actually faster by 4 minutes but the second pass took 12 minutes longer. That must of been what made me notice the difference. That is a fairly significant difference, 22% longer. So that small part above must be making a fairly big difference in the encoding time. Different videos will take different amounts of time but I doubt whether 22% longer can be due to the video.

[sh0dan]

* How do you import your source, or "deinterlaced_video".
* What is your output codec?

* Be sure to use "Fast Recompress" in vdub.

But anyhow; Avisynth shouldn't have any speed difference between passes. Since I assume it's XviD, a speed difference between passes is to be expected.

[Didée]

My 2c on this: From the posted code snipplet, there should be no speed penalty at all.

Other things to consider:

a) Different video content very well may have impact on encoding speed. Encoders are complex, and internal features like early search termination and whatnotelse may lead to different overall encoding speeds for different source files.

b) Edge directed interpolators like EEDI are quite sensitive to the actual content: on some content it computes slower, on some faster. So, if EEDI was part of the deinterlacing process, overall speed may vary noticeably for different source files.