Video conversion service advice? also HuffYUV vs DV
Hello again dear experts :)
Since I kept stumbling on difficulties to find properly working hardware, I've decided to let most of my homevideo tapes (the real precious ones) get ripped by a professional (although that doesn't mean I haven't learned a lot of useful stuff here that has helped in deciding on how I'd like to get it done, which proved useful in selecting a pro). In terms of analogue equipment, this guy seems to be the best choice there is available around here, since he has been passionately collecting and maintaining high end equipment (video brackets, tbc's etc.) for decades. Besides that, he's also the only pro I could find who didn't object when I asked him to rip to harddisk in such and such a way as I'd have done it myself. Most people offering their services in the field of digitalization sadly have proven to be either amateurs that like to make some easy money off their dvd recorders, or a few that stick to their own theories and methods and get touchy if you make a request that strays from that. Anyway, for my reassurance I'd just like to check a few facts here (it'll be quite pricey after all) . 1. As a capture device this particular digitalizer uses a Datavideo DAC-10. Since I'd like him to rip in huffyuv, I'd like to make sure it isn't one of those devices that hardware-compresses to dv-avi forehand. In addition it would be nice to make sure if it's known to be 'accurate' enough. I also read the DAC-10 comes with an 'audio lock' function, but I'm not sure how those work. Perhaps by dropping/inserting frames or dynamically resampling audio like vdub? (For editing purposes I'd like to know if I'll end up with audio that's already resampled, if it'll be possible to tell). 2. Should I ask him if he monitors the tapes as he rips them? From how he said he'd rely on either automatic time/size limits for the files or rip the tapes as a whole, I got the impression he may not. For a higher tariff, he does use high end equipment that can correct chroma and luminance errors, but I'm not sure if they require manual operation. I'm personally just used to basic proc.amp settings (brightness, contrast and such) that often need adjustment in order to optimize the different types of recordings on these compilation tapes of homevideos (which is mostly required due to the difference between inside/outside recordings, and a few tapes that contain recordings from two different camera sources, that each had their own quirks). I also don't feel like paying extra for the optimization of one type of recording that is detrimental for others on a tape. 3. What kind of system would theoretically suffice for playing more compressed huffyuv files? I intend to request rips compressed with the settings predict gradient or preferably even median, but I've experienced a slower playback of such files once before due to unknown causes (with my currently installed ATI AIW 9800 PRO that is, perhaps the 9600XT is a little faster?). I'm running an optimized version XP on a Pentium 4 3.00GhZ. I suspect the bottleneck in this situation could have been the hard drive as well. My main drive is a regularly defragmented 250 gig, which according to specs runs at a maximum of 7200 rpm, but my mobo only supports S-ata1 speeds. Currently I don't seem to have issues with replaying/ skipping through more compressed huffyuv, but by checking what the system requirements for decompression are, I'd like to exclude the risk of ending up with a collection that needs to be reencoded entirely in order to be played back on my current system. In addition I wondered if the ffdshow codec of huffyuv isn't a little faster for decompression than the original (2.1.1)? Which would be wiser to stick with? |
I went ahead and moved this to a new thread, since it's starting a new topic.
Quote:
The main goal of this site is for advertising our media services. While we share knowledge in various ways (guides, forum posts, etc), we do actually hope that many folks will use this information as a guide for selecting a proper service (us, hopefully -- or at least somebody like us) to help them with their projects. For some folks, this means picking a service that does everything -- from recording, to editing, to distribution. For others, they just need piecemeal services. Your desire to get the video captured as HuffYUV is a perfect example. That's all you need help with -- capturing. (At least, that's all you need help with right now!) Quote:
Quote:
The "local option" is typically not the best one. Not to say all walk-in locations are bad, but many are pathetic. Many more bulk-ship tapes to unspecified locations overseas! Yikes! Quote:
Quote:
Quote:
The reason many of those folks get touchy is because they don't know what the hell they're doing. Quote:
Quote:
The only people who pretend these devices are "professional grade" are the companies selling them. I like Canopus and DataVideo products, but when it comes to their DV converter boxes, they are all bark (marketing) and no bite. I never see these in studios or real high-quality conversion facilities, only in the hands of home users and students. Sometimes you'll see these in film conversion services -- amateur home films, that is, the 8mm's grandpa shot in 1950 -- but it's really the only option to conveniently return quality film work. (It's too shaky for DVD conversion, in most cases, to be an "archival grade" solution.) Color on home film tends to be crap anyway, so DV colorspace compression loss is transparent. The same argument could be made for VHS sources, but color values tend to be better, and there is less inherent shake frame-to-frame. DVD-Video and uncompressed are better solutions. Tape is officially dead now too -- everything has moved to disc, drive or solid-state. Nobody likes "eaten" tapes, be it VHS or DV. DV is a decade+ old technology, and it's been escorted out the door by H.264 (for better or worse) and HDV. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
By the way if I come across aggressive on this topic, it's because I've declared war on myth and stupidity, as it relates to this field. I've had enough. Consider this my resolution for 2010. Competing with fools has become tiresome. Rather than just point out why we're the service you should use (or a few of our peers with good service, too!), we've started to point out the services you should avoid at all cost.
For example, a recent post at http://www.digitalfaq.com/forum/show...67&postcount=7 -- idiots. I feel sorry for folks who get duped by the hacks and quacks. |
Quote:
Quote:
In any case, I've asked this guy whether he monitors the tapes. If he'll reply he doesn't, I'll admittedly get suspicious and maybe I'll just let him do one or two tapes first to see how much better the results are than those following from my own attempts. Quote:
The reason I'd like to try out the predict median setting is that I have over 46 hours of material, and I'd like to see all of that backupped on an extra drive as well. At 50 gigs an hour I have enough space for that, at 70 I don't. In any case, I'll run some tests with it since my system should be able to handle it. Thanks. |
HuffYUV generally runs at 30-40GB/hour -- I've never seen it go to 50-70. I mean, 75-80GB/hour is uncompressed YUY2/4:2:2!!
HuffYUV MT runs about 10% larger, but encodes about 50% faster on multi-core. PAL DV isn't as abusive to colorspace compression as it is in NTSC. Give him a tape to try, and see how it goes. It may turn out fine for you. DV is also 13GB/hour, and will still play fine on your computer. |
Yes, damn.. it suddenly hit me that I got uncompressed YUY2 and huffyuv mixed up all this time. This seems to be because huffyuv supports YUY2, plus the terms losless and uncompressed are tempting to mix up, but now all these little inconsistencies I came across (file size etc.) finally make sense.
Concerning the losless aspect, since I apparently got mostly YUY2-captures I wondered if it's worth comparing these with their respective huffyuv reencodes, or shouldn't there be any differences upon decompression/playback (as the term losless suggests)? Like, can huffyuv compression be compared to compressing to zip-files without truly losing any data? (In the case of YUY2-> compressed YUY2, not RGB-> YUY2 I mean). I guess I'll talk the matter of the dv-format over with this guy when I go visit him. Who knows, so far he has presented himself as pretty well-willing, so perhaps he'd be interested in learning of the differences between huffyuv/dv-avi himself. In any case, a try-out tape indeed seems to be a good idea before I hand over the entire collection. |
1 Attachment(s)
Quote:
from wikipedia: Quote:
Quote:
With 5:1 DV compression, you can still get blocks and digital artifacts during motion. It doesn't really happen when DV is used for shooting video, but it does when used as a conversion format. DV was never really meant as a capturing/tape-conversion format, it was developed as a replacement for VHS/S-VHS and 8mm/Hi8, but with quality approaching closer to Betacam SP used by camera crews. (But DV was not as good as Betacam, which led to DVCPro.) The 5:1 compression was partly an issue of tape size, tape speed (physics limitations), and keeping at least an hour or more of shooting per tape. There was also concern about editing it on home computers, so file size and bandwidth was kept down to available speeds of the time, being 5400/7200rpm IDE hard drives and Firewire connections (both very new at the time!) Again, DV was new tech in the age of Pentium III computers in the mid/late 90s. DV is not much different from I-frame MPEG, both being intra-frame encoding methods. (GOP MPEG encodes temporally, interframe, as used on DVD-Video and broadcasting. These are often referred to as "Long GOP" formats.) Temporal = time, FYI. In a 30fps DVD video, a GOP is often 15 frames, so you have 2 GOPs per second. Broadcasters use much longer GOPs, sometimes 100-300frames! So your compression can be spread out across quite a few seconds. DV is prone to color problems and blocks, even during shooting. When used for compression, it tends to magnify these issues. It doesn't help that you can critically compare the before/after tape, unlike real-life shooting. Color problems are mostly due to colorspace compression, using 4:1:1 NTSC (180 samples per line) or 4:2:0 PAL (co-sited 360 sample, alternating lines). Remember that DVD-Video is 4:2:0 NTSC or PAL. While the samples alternate lines, having more of them spread evenly helps retain color fidelity. The common defense to DV is that DV exceeds the color bandwidth of the source, thereby justifying the lower sample count, but I find that to be more theoretical than anything else. In practice, VHS>DV often looks "cooked" compared to the tape, both in contrast and in edge accuracy of colors. Related rant: To further compound problems, some people like cooked video, because it has "bright picture" and "better colors". There's not a cure for stupid, sadly. This is one reason HDTV sets are such a mess, with people wanting the overly-bright and abused image quality, while accurate models go unsold. The goal should still be accuracy! If somebody wants to watch it in butchered form, then they can crank up brightness, contrast and saturation on their TV set. Once the video is cooked, you can't undo it, you're stuck with it. If you want to read more on DV colorspace technicals, Adam Wilt has written about it --- from a shooting and editing/processing aspect !! --- at http://www.adamwilt.com/DV-FAQ-tech.html#colorSampling -- I don't necessarily agree that 4:2:0 is horrible for the capturing/tape-conversion, I think it's better than the 4:1:1 alternative. Another look at colorspace is in a wiki article: http://en.wikipedia.org/wiki/Chroma_subsampling I don't know how credible that article's sources are, so don't examine it too closely. I mostly link to it so you can look at the sample images. Given the choice of formats, I'd much rather have:
I would admit that I dislike MJPEG (Motion JPEG, not to be confused with MPEG) more and more. I'd probably pick DV over MJPEG. It's not so much the MJPEG format, but rather the poorer quality of MJPEG codecs found in 2010. Here's a good colorspace chart from http://www.dvcentral.org/DV-Beta.html Attachment 655 That shows how the colorspace compression takes place. And I didn't even go over the variances in DV, between the different codecs (Canopus, Matrox, Sony, Panasonic, etc). Matrox is probably the best of the four I just listed. Quote:
|
Thanks for some of the arguments against the dv-format. Hopefully that guy will listen to them instead of sticking to the myths surrounding it.
Quote:
In spite of theory though, I have noticed something a little odd upon playback of a particular huffyuv-compressed YUY2-file. As it turns out it seems that it's slightly, but only very slightly more saturated than the original. I basically made bmp-screenshots in MPC (directly, using 'save image as') of the same frame in the following ways: - during playback of the original file (uncompressed YUY2) - during playback of the huffyuv encoding (libavcodec in ffdshow) - as above but with the standalone codec of MPC by disabling huffyuv in ffdshow - during the playback of a directshow-encoded huffyuv version of the file In every case where I used huffyuv, there was the subtle effect of more saturation (mostly in the red chroma noise). At first I thought my eyes were deceiving me, but by switching between screens while focussing on the image instead of the file name I was always able to pick out the one screen of the original YUY2 encoding among these four (like 8 out of 8 times). However, after reencoding the huffyuv file to uncompressed in vdub, the screen of this frame turned out exactly the same as the original. So, now I'm curious, is it theoretically possible that during the playback of huffyuv the reproduction of images can be slightly inaccurate compared to the uncompressed video? All the same I could upload the screenshots if you'd like. |
Colors will always vary slightly due to colorspace, encoder, decoder, matrices and viewing device. Playback on a computer often uses overlay graphics mode, which can differ from standard mode in an editor or preview mode.
I see things like this all the time -- I have to remember to adjust myself accordingly, when editing or restoring. Test clips are always helpful, when in doubt. Sure, post some sample screenshots, that always helps a conversation. |
Alright, I very carefully cropped some screenshots in vdub so the coordinates of each pixel would match the ones in the screens taken in mpc, then resorted to photopaint to determine the RGB value of a single particular pixel in all significant screenshots (I assumed it doesn't matter that the colorspace is automatically converted to RGB here).
As it turned out my earlier observation wasn't incorrect. Huffyuv is played back with slightly more saturated colors than YUY2, but not just in MPC, in vdub as well according to these results. I packed the screens I used for comparison and the results of the pixel test (that can be repeated since I included the coordinates as measured from the top left). Visit this page for the tests.zip file. I also apologize for the randomness of the screen. At some point you just stop realizing what you're looking at. The most significant result for me would be the one conducted on the screenshot from the reconverted capture (from huffyuv back to YUY2), since it implies the colors are the same compared to the original (which is also what the eye tests told me). Nevertheless, it's kind of odd that losless compression would after all produce a color difference upon decompression even without colorspace conversion taking place simply because the compressed data is handled differently. |
5 Attachment(s)
NOTE: Try to upload images/attachments directly into the forum. Instructions at: http://www.digitalfaq.com/forum/show...ages-1529.html.
Also don't use BMPs, use PNG or JPEG images, and then put them in an inline preview as shown in the attachment instructions. I've attached the last group of images for you: 0746-Huffyuv-(fast-recompress;-mpc).jpg (43.4 KB) Attachment 658 0746-Huffyuv-(vdub).jpg (43.4 KB) Attachment 659 0746-yuy2-(mpc).jpg (43.3 KB) Attachment 660 0746-yuy2-(reconverted-from-huffyuv-mpc).jpg (43.3 KB) Attachment 661 0746-yuy-vdub.jpg (43.5 KB) Attachment 662 And your TXT notes: Quote:
What I do see a lot of, however, is chroma noise -- all those color specs. Read more about chroma noise at http://www.digitalfaq.com/forum/show...flaws-565.html |
Hmm it's just that the RGB-values returned by Corel photoshop confirmed exactly what I thought I was seeing (my brightness and contrast settings are quite low btw). I'm not saying these differences cause visible annoyances (especially NOT with increased brightness! I couldn't even bare look at a bright monitor that intently), but that there is a subtle difference in how yuy2 and huffyuv are displayed even when viewed in virtualdub, and that the difference lies in color saturation. That's it, but it's still weird! (And perhaps also the fact that I could make out any difference while expecting there wasn't any.. I admit that I had to look very carefully though).
Yes I'm quire aware of the flaws in these vids. I have a S-VHS player with DNR actually, but that one adds an annoying buzz to the sound output. Tried to remove it in software and by using different cables and what not, but to no avail. Cleaning the audio head didn't help a thing either. This is why I wanted to pass these tapes to a pro. I can only seem to get my hands on flawed equipment and it's starting to cost me more this way ;\ |
Quote:
Once with DNR turned on, for the video. Once with DNR turned off, for the audio. Overlay them in an editor (I use Adobe Premiere for this, when AVI) to sync within a half-frame radius. Or for MPEG, trim the lengths of both to match exactly, using an MPEG editor like Womble MPEG-VCR or Womble MPEG Video Wizard. I've been in similar situations. :o Going back to the variances you measured, being off by one value may be a difference of some other kind. |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.