I bought one of these to use for capturing the old home movies on VHS. After quite a few problems, it finally appears to be working well.
After building ffmpeg from source (November 2016), the USB-Live2 is working as advertised. With unstable video sources, like VHS, it is up to the software to make sense out of the garbage that is produced by this adapter. Newer versions of ffmpeg tend to do a better job. The only snag I've run into is with the audio track being mangled when the video is particularly unstable. Again, this is most likely ffmpeg's fault, and might be addressed in the future.
Since video is very demanding and USB can only move so much data at a time, it's important that you connect this correctly. This goes for any USB video capture device.
The best case scenario is to have the USB-Live2 as the only USB device on the entire system. This is probably unrealistic as we likely need a keyboard to talk to the computer. However, other potentially demanding USB devices like mice, wifi adapters, hard drives, CD-ROM drives, flash drives, etc... need to be disconnected.
You might be able to plug things in such that the USB-Live2 has its own bus. You can use "lsusb -t" to see how the various devices are arranged on your system's USB busses:
In the above, the USB-Live2 is on Bus 02 (cx231xx is the driver for the USB-Live2's Conexant CX23102 chip), while the keyboard/mouse are on Bus 08 and the wifi (rt2800usb) is on Bus 01. Because the USB-Live2 has its own bus, it seems to work fine.
The USB-Live2 will drop frames if other USB devices get in its way. It's best to make it the only USB device on the system.
Other random things to consider. I need to expand this section a bit. Just throwing it out there to get things started.
Once the USB-Live2 is connected, we need to set it up. First, find the device with v4l2-ctl.
According to that, we can use /dev/video0 to talk to the USB-Live2. (/dev/vbi0 is the Vertical Blanking Interval where closed captioning and teletext are transmitted.)
Let's check the current settings:
There's a lot of interesting info there, but most important right now is the "Video Standard" section which tells us our device is set for PAL:
This is fine if you live in PAL-land (most of Europe). However, if you live in NTSC-land (USA, Japan, etc...) you'll need to change the configuration. You can list the supported standards like this:
The list is very long and includes many variations on each of the major standards. Pick the one that suits you best. For me, it's NTSC. We can use v4l2-ctl to configure the device for NTSC like this:
If you have the wrong standard set, you will likely get no video at all since the USB-Live2 won't be able to make any sense out of the incoming video signal.
At this point, it's a good idea to make sure video is working. Plug a video source into the USB-Live2. I use my set-top cable converter box instead of running my old VCR and wearing out tapes while testing.
As a brief aside, I need to mention that there are two main video toolkits for Linux. One is known as "ffmpeg", the other is "libav". They are very closely related as libav is a branch of ffmpeg. As of this writing (October 2016), libav and ffmpeg are merging back together, and ffmpeg is once again becoming the standard toolkit for Linux video. Throughout you will see me mention the commands from both toolkits. E.g. ffmpeg and avconv. Or ffplay and avplay.
Use ffplay (or avplay) to monitor what's coming in:
Note that there is no sound. We need to figure out where the USB-Live2's sound hardware is before we can test sound. ALSA's arecord command can be used to list sound devices:
The motherboard sound hardware is on "card 0" while the USB-Live2 sound hardware is on "card 1". When using ALSA, the proper device name for card 1 is "hw:1". Let's check the audio with ffplay (or avplay):
I'm not sure how to combine the two in ffplay. I assume that ffmpeg would need to be used to combine the audio/video into one stream which could then be piped to ffplay.
Given that our video is on "/dev/video0" and our audio is on "hw:1", we can capture some video to a file using ffmpeg (or avconv):
Let's walk through this command line....
"sudo" says to run this as root. This gives ffmpeg the ability to raise priority if it wants to. I'm not sure how valuable this is. See limits.conf(5) for an alternate (safer) way to give users the same ability to raise priority.
"nice --20" says to raise the priority of ffmpeg by 20. This should give ffmpeg priority over the machine if some other unexpected process comes to life (e.g. updatedb).
"-f alsa -i hw:1" says to force the format of the next file to "alsa" and that the next input file is "hw:1". In other words, use ALSA's hw:1 for audio input.
"-f video4linux2 -i /dev/video0" says to use video4linux2's "/dev/video0" for video input.
"-t 02:10:00" says to record for two hours and ten minutes. Perfect for capturing an entire VHS tape in SP mode.
"-r:v ntsc" says that we want the destination file to use the NTSC video standard. Make sure this matches the USB-Live2's video standard setting or else frames may be dropped. [Need to try dropping this with the latest ffmpeg. I think they preserve the standard of the input now. They used to default to 25fps.]
"-preset ultrafast" says that we want the H.264 codec to use less CPU. This will increase the size of the final video file. However, if we don't do this, the computer might not be able to keep up with the incoming video. Use the "top" command to monitor how much CPU ffmpeg is using and adjust the -preset setting to avoid using too much. Valid -preset settings are: ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow. See the H.264 encoding guide for more.
"test.mp4" is the destination video file. An mp4 file by default uses the H.264 video codec and the AAC audio codec.
Just some random notes on quality control. I need to expand this section.
Frame Drops. Test with a financial channel that has a moving ticker at the bottom. That makes frame drops easy to see.
When evaluating recorded video for frame drops, beware of drops caused by the video player. Slow the video player down to make sure you are seeing the actual recorded video. (E.g. in vlc use the square bracket keys to slow down/speed up playback. 0.5x makes frame drops obvious.)
Audio Sync. Check toward the end of the file where audio sync issues become worse.
Quite a bit of documentation can be had from the command line. For ffmpeg (or avconv), try these:
For help on the H.264 encoder and all of its options:
Digitising VHS Tapes on Linux - Lots of interesting stuff here. Mentions that dropped frames still happen. Doesn't mention rtbufsize.
VHS to iTunes Compatible MP4 - This is where I saw rtbufsize.
Note: The following is a summary of the struggle I went through before I figured out the problem was ffmpeg. Compiling and installing the latest ffmpeg solved all the problems.
With the video apps that come with Ubuntu 14.04, I was unsuccessful at getting the USB-Live2 to work consistently. With avconv (ffmpeg), sometimes it works fine. Other times it captures for a while at 30fps and then the capture drops to 15fps. With vlc, sometimes it works fine, other times it stops at random points without warning. Possible sources of the problem:
I've been experimenting with capturing from my cable box in two hour chunks. This appears to work fine. So it appears that the issue is the unstable signal from the VCR. Is the hardware having trouble with the signal? Or is the Linux driver handling errors poorly? Perhaps it is passing them on to vlc and ffmpeg who then behave differently when faced with bad input. [Exactly!]
Informal statistical analysis of reviews on Amazon mentioning VHS:
Given the 30 reviews on Amazon that indicate that this works fine in Windows for transferring VHS, I would say the problem is in the Linux drivers/software. Actually, there are two reviews that indicate success with VHS in Ubuntu 12.04. Could be a regression.
One solution that should work fine would be to get a VCR with Time-Base Correction built-in. These go for around $300 on ebay. This would get me through the project without having to dig through the drivers and improve them.
Other options:
I also tried the Canopus ADVC-100. Turns out its DV implementation is non-standard and is only supported in very old versions of Linux. Unfortunately I was unable to use my Sony Digital 8 camcorder (DCR-TR7000) as a pass-through device. Somehow, Linux's 1394 implementation appears to be in "DV Out" mode to the camcorder and takes priority over the analog ins, thus defeating pass-through mode. I know that I've done this successfully with Windows and Adobe Premiere.
Copyright (C) 2016-2020, Ted Felix
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. See The Free Documentation License for the full text of this license.
<- Back to my Linux page.