Thursday, March 25, 2004

New VirtualDub Filter Chain

Changed up my standard filter chain for clean OTA recordings on my SVHS VCR:

1. Capture at 704x480 YUY2 29.97fps 48kHz audio

2. Static Noise Reduction, Noise threshold 6, Interlaced. This gets rid of some of the noise in the signal.

3. Deinterlace (unfold), this is done prior to any filters that aren't interlace-friendly. What actually happens is that the image goes from being 704x480 interlaced to 1408x240 deinterlaced with the A/B frames side-by-side.

4. Dynamic Noise Reduction, Noise threshold 6, Not sure if this filter is interlace-friendly... if it is, I can get rid of the unfold/fold steps. Good for eliminating any shimmering noise between frames.

5. Deinterlace (fold), changes the stream back to interlaced.

6. Crop any tracking noise (usually 4 pixels), Resize using Lanczos3, interlaced to 352x476 (480 minus the number of lines cropped due to tracking noise), then expand/letterboxed back to 352x480 which centers the result vertically on the screen. The old fill method resulted in large black borders on the bottom of the frame if there was a lot of tracking noise to remove.

Speed: It took 24.4 minutes to convert a 7.2 minute clip, but CPU usage was only around 50% on my AthlonXP 2600+. Assuming I can identify the bottleneck, it could've been done in 12-13 minutes (around 1.4-1.5x) which is a good bit faster then 2D Cleaner or the Smarth Smoother filters.

posted by Wuphon's Reach at 6:50 PM

Wednesday, March 24, 2004

VirtualDub Filtering Speed

Here's some benchmarking that I did today on my AthlonXP 2600+ (DDR333, PC2700, CL 2.5 RAM). File sizes are the output file (compressed using PicVideo MJPEG Q20) along with the amount of time required to convert.

966Mb - Raw capture file (1 min 47 sec), 720x480i 30fps, compressed using PicVideo MJPEG at Q20 (roughly 9 Mb/sec).

2D Cleaner
947Mb 06.0 min (3.4x) - r1 t10
833Mb 18.7 min (10.5x) - r3 t10
799Mb 43.0 min (24.1x) - r5 t10
920Mb 06.0 min (3.4x) - r1 t10
821Mb 11.0 min (6.2x) - r2 t10
780Mb 18.2 min (10.2x) - r3 t10
(radius of effect is key factor)

Smart Smoother High-Quality
951Mb 05.9 min (3.3x) - d3 t20 m10 avg w/ diff
808Mb 08.5 min (4.8x) - d5 t20 m10 avg w/ diff
772Mb 12.4 min (6.9x) - d7 t20 m10 avg w/ diff
932Mb 05.9 min (3.3x) - d3 t50 m30 avg w/ diff
769Mb 08.6 min (4.8x) - d5 t50 m30 avg w/ diff
728Mb 17.6 min (9.9x) - d7 t50 m30 avg w/ diff
(diameter is key, threshold plays a minor secondary role in time required)

Static Noise Reduction
1024Mb 04.2 min - t4
960Mb 04.1 min - t8
942Mb 04.4 min - t12
938Mb 04.3 min - t16
933Mb 04.2 min - t24
930Mb 03.9 min - t32
(this test was constrained by disk throughput, CPU utilization was about half, so with fast enough disks those time values should be divided by 2, achieved throughput was roughly 2.4x, but could've been as low as 1.2x if disk speed was faster)

posted by Wuphon's Reach at 6:01 PM

VirtualDub Filter Tests

Testing out some more filtering per a discussion over on the DVDRHelp forums.

On a side note, I've gone back to only putting (3) hour-long TV episodes on a DVD (roughly 133 minutes once commercials are removed). The 2900kbps video rate seemed to be too noisy. Doing a VBR average rate of 3750kbps, the disc only came out to 3.78Gb, leaving a goodish amount free. Allowing for 45min per ep (135min total), that should work out to 3.84Gb. My goal is to fill the disc up to the 4.2Gb point (leaving 0.17Gb free for QuickPar PAR2 recovery data). So I have room to bump my average bitrate up by 9% to 4100kbps.

I still might try out the lower bitrate again in order to fit (4) on each disc - now that I've tweaked TMPGEnc to give better results. (That bitrate will probably be 3100kbps.)

FYI, I found a good scene that illustrates (somewhat) what happens when you have too low of a bitrate or the motion search precision (MSP) is off. This is from the start of a Law & Order episode and is a shot of the river with lots of little ripples reflecting the blue sky against the dark water. The effect is much easier to see when watching the clip, which was encoded at 2900kbps using an MSP setting of "Motion Estimate (fast)". Still, if you look closely, you'll see the blockiness around the highlights where the macro blocks weren't able to flesh in the details.


(right side shows a little of the artifacting)


(look left and below the dark bump in the upper left to see some blocky areas)

posted by Wuphon's Reach at 1:38 PM

Monday, March 22, 2004

TMPGEnc Motion Search Precision Benchmarking

Benchmarking some different "motion search precision" settings in TMPGEnc Plus. I was just using "Motion Estimate (fast)", but while encoding some anime, I've found some motion errors on certain frames. The error looks like bleed-over from the next/previous frame, different then an interlace artifact (which looks like a comb). Interestingly, looking at some screen captures from my Key the Metal Idol DVD, I see a good number of motion errors on there as well.

TMPGEnc has (6) settings for the "motion search precision". These were all done on 720x480 30fps source material (MJPEG Q20), variable bitrate at 6500kbps avg, and 10bits of precision. The test clip was 1 minute 51 seconds in length (call it 1.85 min for rough guess) and the system is an AthonXP 2600+ with DDR266 RAM (PC2700) CL 2.5.

Lowest Quality - 6.1 minutes
Low Quality - 6.5 minutes
Normal Quality - 7.5 minutes
High Quality - 11.1 minutes
Highest Quality - 18.2 minutes
Motion Estimate - 7.3 minutes

So High Quality is roughly 6:1 (6 min to encode 1 min of source). It's about 50% worse then the "Motion Estimate" method that I was using, but gives nicer results.

On the P4 1.6Ghz laptop, it ends up being more like 12:1 or 13:1, but that's at 75% CPU utilization. Since I just queued up around 180 minutes of source material, that CPU will be busy until sometime Wednesday (oh boy!). Some days I seriously consider getting a dual-CPU box for when I fall behind. This is my 3rd attempt at encoding these 8 episodes and it's eating up a ton of space that can't be freed until I push it out to DVD-R and check it.

Update: If you go into TMPGEnc's "Environmental Setting: CPU" dialog, there's a way to provide TMPGEnc with a cache for the 2-pass VBR data. Apparently, without the cache, TMPGEnc only records a single "Q" value for the entire frame, but with a cache it can go much finer. Or something like that... I'm rather fuzzy on the details. However, enabling the cache and setting the cache limit to a decent value like 15Gb (3 hours or so) will speed up VBR-style encoding. (Some folks say +30%.) On the laptop, I set it to 4Gb since I'm always encoding short 5-25 minute clips (which only needs 1-3Gb or so); the desktop got set to 12Gb since I use that box to encode very long clips.

posted by Wuphon's Reach at 6:37 PM