Tweet
A question regarding HuffYUV file decompression....
First of all, although I don't (as a rule) post to the board, I've been an avid lurker for about 2 years now, and thre is simply no way that I can thank all of you for the guidance that you've given me in setting up a multimedia-capable computer. It's been built and generally tweaked acccording to the specs that have been espoused here from time to time, and I have to admit that I'm frankly astounded at what it's now able to do.
Over time, I've managed to collate a G-200 Marvel, an ASUS P3B-F, a striped 90-GB RAID array with an FT-100 controller, recycled my ISA AWE-64 SB soundcard into the new configuration, and since I completed the upgrade with a slot-1 Intel P-III 850 CPU (which is a little slow for these times, I know, but a drastic upgrade for **me**) I've really been in seventh heaven, getting some hands-on experience with captures, editing and encoding (well, OK, the encoding part isn't so exciting, but the results can certainly be worth the wait...!)
But here's the problem. I capture to the array at 704 x 480, using a combo of AVI_IO and HuffYUV, do editing in MSP 6.0, and then frameserve with VirtualDub to encode with TMPGenc (12a) in an SVCD format. The difficulty that I've run into is that I think I may have had a setting wrong in HuffYUV for my previous captures, and I just need to either confirm my mistake, or find an easier way to do a necessary step...
Before yesterday, I didn't have the "Always suggest RGB format for output" box checked in HuffYUV, mostly because I wasn't certain of its function. As a result (I think), after much experimentation I was able to determine that for files that didn't require any editing in MSP 6.0 (and were therefore just the raw capture files), VirtualDub was sending those files **as-is**, to TMPGenc, which was attempting to encode the compressed image, giving me strange color and interlace problems in the resulting MPG files.
I happened to discover this by comparing the results of an encoding of a sample capture file, the only difference being that one version had a slight edit applied through MSP 6.0, which I completed using MSP's Smart Trim function. The edited file turned out beautifully, while the frameserved raw file encode turned out with the same color and interlace problems that I'd seen before. I was finally able to put 2 + 2 together and realized (after looking at a comparison of the source file sizes, as MSP's Smart Trim saved its output to a different filename) that the difference was that MSP had saved the edited file in decompressed form, and that **that** was what was making the difference!
Now my newbie question is this: since I've now checked the "RGB output" box in HuffYUV, will VirtualDub in frameserve mode now automatically decompress the source capture file before sending it on to TMPGenc, (which would be the best solution, to avoid having to store uncompressed data on the RAID array-- even thought there's room), or is there a really basic command that I could use in MSP 6.0 to convert the files over to an uncompressed format? Smart Trim only works if you make an actual edit in a file, and that's not always necessary with each of the spill files that make up a long capture...
I hope I've laid out the problem clearly (if not terribly concisely), and I thank **everyone** who's had the fortitude to read this far, and offer advice and assistance... it's much appreciated!! :^)
-Joel Cairo
Over time, I've managed to collate a G-200 Marvel, an ASUS P3B-F, a striped 90-GB RAID array with an FT-100 controller, recycled my ISA AWE-64 SB soundcard into the new configuration, and since I completed the upgrade with a slot-1 Intel P-III 850 CPU (which is a little slow for these times, I know, but a drastic upgrade for **me**) I've really been in seventh heaven, getting some hands-on experience with captures, editing and encoding (well, OK, the encoding part isn't so exciting, but the results can certainly be worth the wait...!)
But here's the problem. I capture to the array at 704 x 480, using a combo of AVI_IO and HuffYUV, do editing in MSP 6.0, and then frameserve with VirtualDub to encode with TMPGenc (12a) in an SVCD format. The difficulty that I've run into is that I think I may have had a setting wrong in HuffYUV for my previous captures, and I just need to either confirm my mistake, or find an easier way to do a necessary step...
Before yesterday, I didn't have the "Always suggest RGB format for output" box checked in HuffYUV, mostly because I wasn't certain of its function. As a result (I think), after much experimentation I was able to determine that for files that didn't require any editing in MSP 6.0 (and were therefore just the raw capture files), VirtualDub was sending those files **as-is**, to TMPGenc, which was attempting to encode the compressed image, giving me strange color and interlace problems in the resulting MPG files.
I happened to discover this by comparing the results of an encoding of a sample capture file, the only difference being that one version had a slight edit applied through MSP 6.0, which I completed using MSP's Smart Trim function. The edited file turned out beautifully, while the frameserved raw file encode turned out with the same color and interlace problems that I'd seen before. I was finally able to put 2 + 2 together and realized (after looking at a comparison of the source file sizes, as MSP's Smart Trim saved its output to a different filename) that the difference was that MSP had saved the edited file in decompressed form, and that **that** was what was making the difference!
Now my newbie question is this: since I've now checked the "RGB output" box in HuffYUV, will VirtualDub in frameserve mode now automatically decompress the source capture file before sending it on to TMPGenc, (which would be the best solution, to avoid having to store uncompressed data on the RAID array-- even thought there's room), or is there a really basic command that I could use in MSP 6.0 to convert the files over to an uncompressed format? Smart Trim only works if you make an actual edit in a file, and that's not always necessary with each of the spill files that make up a long capture...
I hope I've laid out the problem clearly (if not terribly concisely), and I thank **everyone** who's had the fortitude to read this far, and offer advice and assistance... it's much appreciated!! :^)
-Joel Cairo
Comment