Log in

View Full Version : Issues of Balanceborders with ConditionalFilter


adhaing
18th November 2014, 06:18
Hi, guys.
I'm pretty new to AVS and video encoding, lately encountering inexplicable issues in fixing side dirtylines with ConditionalFilter.
Script was quite simple, that I wanna apply Balanceborders to a couple ranges of frames, like this

FFVideoSource("BDremux.mkv")
Crop()
ConditionalFilter(last, fillmargins(0,0,2,0).balanceborders(0,0,2,3)), "SceneType", "<", "1")
ConditionalReader("fix.txt", "SceneType")
Spline36Resize()

#fix.txt

TYPE int
DEFAULT 0

R 5810 6112 1
R 7319 8810 1
R 31554 32342 1
R 33987 34861 1
R ...... 1
R ...... 1

......



It's BDMV to 720p encoding.
Before frame#5810, x264 ran normally at a speed of 4.xxfps with full cpu usage. When it moved to frame#5810 (the first frame of my first "gotta-fix" range), x264 speed abruptly went down to 2.5xxfps and cpu usage collapsed under 20%, which went on until the range was passed. Then the cpu usage came back to 100% and x264 speed slowly rose. When moving to the next range, that happened again.
Worse still, during the ranges the sharply-depressed speed kept dropping bit by bit. e.g. When it was encoding around frame#20000 (non-processed part), x264 speed was 1.2xx fps. Now it's encoding around frame#32000 (within the third range) at a poor speed of 0.6xxfps.

Due to my frail equips, the trims/applyrange methods failed soon after x264 began, so I chose ConditionalFilter. I heard it's trigger-like without consumption for pre-buffer or sth(NONE of these presentation professional but my own childish metaphor:)). But now I'm really confused about its efficiency. Does it just "render" the frames one by one from the first pixel even if I set the "R" tag?

Would you gurus please show me how it work exactly and why would I suffer such a speed collapse (except for my equips:cool:)? Thanks in advance.

-----And my equips:
-----Win7 x86
-----AMD Phenom II X6 Processor
-----2x2GB DDR3

colours
18th November 2014, 08:44
The encoding speed x264 reports is not the "current" encoding speed, but the speed averaged over all the frames processed thus far.

What's happening here seems to be that fillmargins.balanceborders is taking a disproportionately long time to process each frame, which is certainly abnormal. See if the slowness persists if you use ReplaceFramesSimple (http://forum.doom9.org/showthread.php?p=1644971) instead, or if you do a no-op, like ConditionalFilter(last,last,[…]).

Alternatively, you could just crop every frame equally before resizing and be done with it.

adhaing
4th August 2015, 05:43
Thanks, colour.
A bit late though. XD