S-video capture on Linux via ATI USB card, FFmpeg - recommendations?
1 Attachment(s)
Hi all,
I am experimenting with a Linux-based workflow to capture video from a Sony CCD-TRV66 Camcorder directly to an ATI TV Wonder HD 600 USB card. (The total specific financial expenses have been minimal so far: an S-Video cable, the USB adaptor, a pack of Hi8 blank tapes to experiment on later and the higher electrical bill due to reading things online.) The eventual aim is to digitize some old (but in very good shape) 8mm/Hi8 tapes; much later, I may move on to VHS tapes (of much less quality). For now, I am concentrating on the capturing/post-processing phase, bypassing tapes (and TBCs/other analog filters) altogether and using the Camcorder as a webcam; I will likely have more questions later! That's about it for my analog video (ignoring audio) sources for now. In case anybody finds it relevant, for current video production, I use (in increasing order of importance and advance warning):
I appreciate all the help and suggestions anybody may have. I am in no rush and, judging by the amount of time I've already spent reading this site, certainly not afraid of reading long technical explanations, so even pointing me to the right Wikipedia pages would be extremely helpful. (My background is in mathematics and computer science, so prior to finding this site a month ago, my understanding of analog electronics was limited to "if the connectors fit, why shouldn't it work?". According to my browser history, I am also happy to learn electrical engineering theory for its own sake.) (a) Capture hardware (video) Judging from the forums here, the ATI TV Wonder 600 is about the best I can do for capturing an S-video signal through USB, and I can do a little bit better if I go the AGP path. (It is unclear to me how the Blackmagic products compare.) Does this remain the case even if I increase my spending? (Does the answer depend on the quality of the S-video signal?) In my specific situation, the 8mm/Hi8 tapes are in good condition (mostly first-generation recordings on previously blank tapes, then stored cleanly, dryly and at room temperature), so signal correction hopefully is not needed. Assuming hypothetically optimal 8mm/Hi8 tapes (or bypassing them altogether), how much room for improvement is there? My understanding of 8mm/Hi8 tapes is that the S-video signal is not the limiting factor; otherwise, those old camcorders would have component video outputs. I will probably get a green AVT-8710 off of eBay just to experiment with. (b) Capture hardware (audio) Similarly, is there much to be gained by using better hardware to capture the audio, or are the 8mm/Hi8 tapes and the tiny Camcorder microphones already the bottleneck? I would experiment with connecting my M-Audio M-Track Plus, except it's in a separate country from the Camcorder. (c) Video noise from the camcorder Using the camcorder in webcam mode (i.e., before degrading the signal by involving tapes), I get a fairly faithful on-screen capture using FFmpeg via: Code:
ffmpeg -f v4l2 -video_size 720x480 -i /dev/video1 -vf hqdn3d=10 -vcodec rawvideo -f avi -framerate 30000/1001 - | ffplay - For better for worse, the CCDs produce a staggering amount of noise! (The Camcorder's internal viewfinder shows the same level of noise, so I'm pinning it on the CCDs and not something else in the chain. Unless, of course, there is noise produced between the CCD and internal viewfinder.) Can (or should) anything be done about this noise prior to digitization? I assume not, as the signal is accurately transmitting what the CCDs capture. The ATI USB 600 driver allows sharpness adjustment, on a scale of 0-15, where the default of 0 indicates least sharpness. As well, FFmpeg incorporates a denoising filter called hqdn3d. For reference, I have included various screenshots taken at various hqdn3d (FFmpeg) and sharpness (driver setting) levels, included in the attachment screenshots.zip. (The raw shots were captured with something equivalent to Code:
for $z in 0 5 10 15; do ffmpeg -f v4l2 -video_size 720x480 -i /dev/video1 -vcodec rawvideo -f avi -framerate 30000/1001 sharp$z.avi; done Code:
for z in 0 5 10 15; do cp sharp$z.avi sharp$z-0.avi; for q in 3 9 27; do ffmpeg -i sharp$z.avi -vf hqdn3d=$q -c:v rawvideo sharp$z-$q.avi; done; done One thing I find interesting is that as I increase the driver sharpness level, a white gap around the "Sony" text appears. What is this phenomenon, and what filter is the ATI card using (or how is it doing it)? Wikipedia links are welcome here! (d) Other capturing parameters In addition to sharpness, the ATI drivers on Linux have the following proc amp controls:
More subjective questions: is there supposed to be a huge trade-off between capture quality and patience/time here? When capturing from tape, is it normal to have to make multiple passes to fine-tune settings, and get the timing right between scene changes? (e) Streamlining all of this in Linux I'm happy to report that the ATI TV Wonder HD 600 USB card working more or less out of the box on my Ubuntu 14.04.1 LTS system. All that is needed is to download the firmware file. Finding good tools is definitely harder. In theory, all the functionality you need to capture is there, but spread across disparate ad-hoc command-line interfaces that you need to cobble together yourself. I'm guessing that functionality-wise, FFmpeg seems roughly equivalent to VirtualDub, except that you need to do everything on the command line. Is this so? (There is also a Linux port of Avisynth called avxsynth.) Does anybody have any suggestions here? So far, I've been using ffmpeg to record/filter/encode, ffprobe/VLC to view, and qv4l2 to test USB connectivity and tweak/preview capture settings. I have a Windows 7 installation in VirtualBox, so I could use that to process video if necessary, just not for capturing. (f) Capture functionality on a stick Back in the day, there used to be "Linux on a disk" projects -- stick a boot floppy into an abandoned computer, and suddenly you have a free router. I'm currently thinking about something similar, to capture from a laptop's USB capture device and potentially stream the Huffyuv/Lagarith/etc output somewhere else where it can be more easily handled. Has anybody thought about this? It would be nice to be able use a MacBook Pro as a capturing laptop, and I really do not want to mess with dual-booting Linux or Windows XP on such a thing. (I already gave up trying to get the ATI USB card working on Windows 7, anyway.) (g) Future-proofing I anticipate that my primary storage and distribution channel will be the cloud, using Amazon S3 or something similar, and that I will hopefully only have to transcode if somebody asks for the DVD. Given this, is there much long-term (i.e., a few years out) disadvantage to settling on VP9 or H.265 for the codec, and how do I know when it's safe to do so? Chromecast unfortunately does not support these codecs yet, but I care more about things like further standards (and extensions?) stabilization and pending encoder quality. On the other hand, it's simple enough to just dump everything on the cloud now and wait it out now. Assuming a 3:1 lossless h265 compression ratio, for an encoding rate of roughly 23GB/hour (720*480*2*30*60^2 / 1024^3 / 3) and S3 Glacier storage costs of 1 cent per GB-month, that's under 3 dollars to store an hour of video for a year... Thank you for reading this post! This site has been a fabulous learning resource for me so far. Any comments are much appreciated, and no rush to reply, please -- I am in the midst of some travel and won't have access to the Camcorder for a while, anyway. |
1 Attachment(s)
Welcome. I doubt you'll find much assistance with Linux here, but I'll respond where I can. General interest in video on Linux seems to be more about low-cost, not high-quality.
Quote:
So do you care about getting the best possible S-Video capture, or just the best possible S-Video capture from tape? Color separation differences are certainly noticeable between capture devices if you compare a computer-generated signal, but not if it's recorded to tape first. Quote:
Since you have camcorder-generated menus that we know should be the same pixel value across time, if you really want to test the level of noise the capture setup itself introduces, make a capture of a menu and do difference analyses. Subtract current frame minus previous frame + amplification for a visual view, or do measurements. (I'm not sure exactly which can be used but perhaps PSNR or SSIM.) Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.