Last updated 10/05/2001
I've been incredibly lazy these past 4 months, not bothering with my homepage. Here is a preliminary version of dvspoof(ECC) - my contribution is the ECC-routines. The original dvspoof (by Andy Kromkamp) can be downloaded from this link.
In my spare time, I've been reading this book about ECC codes. The math and theory is hard for me to follow, but fortunately the book offers plenty of example applications. My original goal was to implement a Reed-Solomon ECC code, but my reading has progressed slowly. Instead, I just opted for the easy way out, and picked a Hamming parity-code (which I already knew about beforehand.) I'm hoping my self-study will progress to the point where I can field-test a more-powerful RS ECC code. In the mean time, the dvspoof(ECC) package works just like the original dvspoof (
The encoder packs 64 data frames into an ECCblock of 72 AVIframes (64 data + 8 parity.) This yields a nominal ECC-overhead of +12.5%. The error-protection data is calculated across frames (interframe protection.) The decoder is capable of correcting any single bad frame out of an ECCblock. It can also detect any 2 bad frames within an ECC-block, but is unable to correct either frame. Beyond 2 bad frames per ECC-block, the decoder's error-detection reliability falls below 100%. This is somewhat of an oversimplification of the system's correction-capability - in reality it's better to think of the ECCblock as a vertical "stack" of frames. Pretend that each frame is a flat sheet of paper, so then 1 ECCblock is a stack of 72 sheets, nicely arranged in one heap.
|<----- 72 sheets ------>|(1 ECCblock)
|\ |\ |\ |\ :\ |a\ |a\ |a\ |a\ :a\ <- 'a' column |bd| |bd| |bd| |bd| :bd: <- 'b' column, 'd' column |ce| |ce| |ce| .. |ce| :ce: <- 'c' column, 'e' column \f| \f| \f| \f| \f: <- 'f' column \| \| \| \| \:
Each sheet of paper has a surface area of 102524 units (bits.) If we look straight down on the stack, we can divide the stack into 102524 columns, each column is 1-bit x 1-bit, and 72 bits tall. In our imaginary stack, the ECCblock can tolerate up to 1 error per column. So theoretically, the 1 ECCblock can correct up to 102524 errors, provided those errors are distributed as exactly 1-error per column. As long as 2 or more errors don't occur in the same column, we're ok.
The Digital8/DV camcorder (which is dvspoof's target medium) already applies powerful Reed-Solomon ECC to protect data within individual frames. Applying a Hamming parity-ECC in the same fashion adds no benefit. However, the Digital8/DV tape format lacks interframe ECC-protection. This is where the Hamming parity-ECC can increase data-integrity, although not by much.
I just realized that I never posted my 'softDVD' roundup. I had done most of the writeup back in March/April, but simply forgot to post it. Rereading what I wrote has been a lot of laughs. I now have a much better idea just how HARD it is to maintain objectivity. First of all, I established some baseline criteria for a 'grading system' (chuckle.) The 'grading system' is supposed to represent increasing levels of visual quality and decoding acceleration. Instead, it just ends up favoring the ATI boards (for performance), and the ATI boards (for visual quality.) There are some very noticeable differences in image quality among the tested VGA chips, especially under certain viewing circumstances. However, in a standard viewing scenario, the differences are minimal. I could only discern differences because I used the played the same clip over and over again, on the various test cards. And even then, differences were hard to spot.
The one exception was downscaling quality. Boards without bilinear reduction stood out with awful quality. The SiS305, Trident Blade3D, ATI RagePro and RageXL lacked lacked bilinear reduction of any kind.
Last November, I spent a few weekends designing a digital-logic circuit to emulate a CRT text controller. I finished the design, tested it on an XS40-010XL FPGA board, then put it on the shelf and forgot about it. This past week, I rediscovered the lost project, and focused on polishing it for public release. The last few bugs (like a horizontally misaligned text-screen, incorrect end-of-line wrapping, and incorrect start-of-page address) have finally been squished! Check out my Verilog HDL stuff. (Note, that portion of my wwwpage is only of interest to hardware designers.)
I'm back! During a weekend in early March, an automated Tripod script removed my homepage. In the time since, I contacted Tripod and they reactivated my homepage. I'm still restoring website files from a backup site, so a few links might not work.
Tripod has responded! Due to a 'glitch' in one of their automated maintenance scripts, several Tripod pages were inadvertently removed. Tripod is attempting to restore all homepages.
Anyway, I've updated my preliminary PCDVD-test report. Remember, it's just a preliminary report. You can find it in the softdvd section of my links below.
..to older news/rants
I haven't yet restored all my files from my geocities page If you encounter a broken-link or missing-file, try my backup site at http://www.geocities.com/liaor2.
Most of the stuff on my page is pretty old...just warning you
http://www.concentric.net/~psilon - VirtualDub homepage, free linear MPEG/ASF/AVI to AVI editor
http://members.home.net/beyeler - BBMPEG homepage, MPEG1/2 encoder for Win95/98
http://www.inmatrix.com - home of DVDGenie, a nice tweaking utility for software DVD players
http://www.avault.com/pcrl (The PC Release List! Go here for the latest game releases)
http://www.next-generation.com (another on-line gaming magazine)
Websites of some friends...
http://www.kotek.com/kenhsu - Ken Hsu
http://www.mit.edu/~emin - Emin Martinian
http://www.stanford.edu/~mikeym - Mike Malkin
http://www.ChaoticGood.net - John Tchoe
http://personal.www.umich.edu/~davidmwu - David Wu, friend from back when I was at U-M Ann Arbor
© 2001 email@example.com