Avoiding duplicate frames while encoding VCR output using MEncoder

August 16, 2007 4:45 AM

Using MEncoder on Fedora 7 Linux and a bt878 TV card, how do I avoid or work around duplicate frames when encoding video from a VHS tape?

I have a 1Ghz system with 1GB of RAM running Fedora 7 Linux as its OS. It has a bt878 chipset TV tuner card with RCA video in. I've downloaded and installed MPlayer and MEncoder using yum and the Livna 3rd-party repository. I have a VCR, and it's video out goes in the video in of my TV tuner card.

When I try to run MEncoder to encode the video output of my VCR, it generally works fine. However, with some tapes, I will get many duplicate frame warnings. When I play back the resulted video file, I obtain many ghost or looping images from frames preceding the current one being played. The audio stays fine.

This happens with some tapes. With others, I will get very few or no duplicate frames at all. When I view those tapes live on my computer using my TV card and a program like TVTime or xawtv, or using a real TV, everything looks fine. The VCR system I have is quite recent, as it was bought brand new just around four years ago and has good picture quality and its auto-tracking feature is great. (WIth some old tapes that I have, this is really handy.)

The command I tried initially is the following:

mencoder \
-tv driver=v4l2:device=/dev/video0:input=1:normid=1:width=640:height=480 \
-ovc lavc -ofps 29.97 -lavcopts vcodec=mpeg4:vbitrate=1800:vhq:v4mv \
-oac mp3lame -vf harddup

For the -lavcopts, I've tried several options, including different codecs and framerates. I also tried to use the "harddup" option, but it has no effect. I also tried resolutions like 720x576 and 320x240, but this also doesn't help.

Also, I'm at my parents' home and keep in mind that they only have dial-up. If I really have to, I'm willing to download more software. If I really can't complete the transfer of my tapes by Saturday, I may just bring those tapes back with me, buy a USB TV tuner for my Mac mini, and transfer the tapes there instead.

Any suggestion would be greatly appreciated. Thanks in advance!

posted by remi to computers & internet (9 comments total)

What is the quality of the recordings if you just record the channel used to watch the VHS tape on your computer?
posted by ijsbrand at 6:09 AM on August 16, 2007

I tried at many times to hook-up the coax cable to the TV card. However, it seems the tuner itself can't pick up any channels. I think that part may be broken, but the RCA video in is still working great and I have no problem watching TV live (using the VCR as the tuner) via that connector.
posted by remi at 6:14 AM on August 16, 2007

I think you're looking for 'telecine'. because of the different scan rates between TV/Film/computer, there is some duplication of frames, in order to keep things synchronized.

however, I don't remember off hand which way you want to go in this situation.
posted by ArgentCorvid at 7:00 AM on August 16, 2007

Sorry, but this is from distant memory; lately I've been fortunate to be playing with mythtv and a dvb-s card.

I think something that will give you decent results is:

mencoder \
-tv driver=v4l2:device=/dev/video0:input=1:normid=1:width=640:height=480 \
-ovc lavc -fps 29.97 -ofps 23.976 -vf pp=fd,softskip,hqdn3d
-lavcopts vcodec=mpeg4:vbitrate=1800:vhq:v4mv -oac mp3lame

softskip will make sure that pp=fd (deinterlacer) will run first, and I *believe* that the mplayer code tries to drop frames similar to others, so one has a decent quality stream at the end.

On the off chance that the vcr to tvcard is doing telecine, then replace "pp=fd" with "filmdint" which tries to do inverse telecine, and if that fails it considers deinterlacing.

Personally, due to a week cpu (athlon 850), and hating interlace issues, when I only had a tv card, I would capture at 640x240 with a constant quantizer of 2, and later compress to a reasonable bitrate and scale to 640x480 (stupid STB on the upstairs tv won't use the aspect ratios) . If you use 640:240 then eliminate "pp=fd,softskip," from the command line.

if mplayer doesn't intelligently drop only frames similar to the others, I know that transcode's modfps filter will convert frame rates and keep buffers to allow it to drop the frame most similar to the frame before it.
posted by nobeagle at 10:54 AM on August 16, 2007

I tried your command, nobeagle, but it didn't help.

I've posted an short example video of what is happening, linked below. I used the command above, with the Lame codec for the audio. It's at 640x480, and I tried making the output at 23.976 fps like suggested and then 25 fps, and I get the same results.

http://files.remino.net/upload/poorvideo.avi

The audio is intact. But, notice in the video where some frames "kick back." I have no idea how to resolve this.

Is my TV tuner card faulty? The tuner itself doesn't appear to work. Whatever cable I plug in (the TV cable or the VCR cable from its VHF output), the tuner just gives white noise. And I've noticed that some frames do "kick back" when watching the TV live, like the issue I have in my encoded videos, but far less often.

Any ideas?
posted by remi at 11:23 AM on August 16, 2007

I'm at work, so I have no sound, and had to "view" the video by using "mplayer -vo jpeg" and looking at the jpeg. But I see the "kick back" artifacts that you mention. I would actually suspect a bug related to the video for linux drivers; the card itself likely doesn't have the resources to cache/buffer previous frames. However, I can say that the "kick back" effects are absolutely not coming from interlacing or telecine.

I don't know what to make of the tuner not working - I'm guessing that you're correctly changing the inputs to actually get white static. But I'm only used tv cards with s-video which gives one a nice green background when there's no input. What happens if you record from the RCA inputs with the VCR turned off? Hopefully not white static.

I'd suggest attempting to append :fps=29.970 to the options given related to the v4l card itself.

-tv driver=v4l2:device=/dev/video0:input=1:normid=1:width=640:height=480:fps=29.970 \

Unless you're in PAL land, I'd stay away from 25.0 fps when working with tv. 30000/1001 (29.97) or 24000/1001 (23.976) are used with NTSC.

As some hail mary attempts, try using "v4l" instead of "v4l2" (I believe that fc kernels include the v4l1 compatibility) and/or telling the tvcard ":fps=23.976" and mplayer "-fps 23.976 -ofps 23.976" . Failing that, I'd
look for a different kernel (more for the different modules), but that will probably be a big download for you.

Oh, and I'm really annoyed at my "week" instead of "weak" cpu in the previous comment.
posted by nobeagle at 11:55 AM on August 16, 2007

I was so tired, I didn't even noticed your typo! Now that you mentioned it, I won't stop looking at it! :P

I think we're getting somewhere. I tried the v4l driver instead. Even though I get way many more "duplicate frame(s)" warnings, the video and audio are in sync, and the video is not "kicking back" like before.

However, the video is all black and white and the bottom is green. I've uploaded a sample of that, linked below. I may just be missing something...

http://files.remino.net/upload/v4l.avi
posted by remi at 1:45 PM on August 16, 2007

Firstly, going from vhs to 29.97 capture, one should not be surprised about duplicate frame issues - sometimes video will look quite similar.

I'm not sure what normid for your video card is.

As a fellow Canadian, you're almost assuredly using NTSC, so about replacing "normid=1" with "norm=NTSC" - the other question which is may be causing problems is outfmt - try using "outfmt=help" and see what mplayer tells you. I believe yv12 would be the most likely candidate for a tv card. As well, it might be good in addition to posting the .avi's to also post the output of mplayer up until it actually starts encoding.

However, looking at the pixels, my brain is having problems imagining what format the card might be returning and what mplayer thought it would be returning. The bottom third being the only part to have color makes me think there's something "off" in the inputs. But I guess this could be explained by getting NTSC while expecting PAL. However, merely specifying outfmt might also clear things up.
posted by nobeagle at 2:23 PM on August 16, 2007

Thanks for all your help and great advice, nobeagle. Unfortunately, I wasn't able to resolve that "kickback" problem.

Time is running out, so I've simply found a workaround to my problem. For some reason, when viewing TV with TVTime or xawtv, lower resolutions will show more kickbacks, larger resolutions will have less. Funny enough, it seems to be the opposite when capturing the video.

I tried mencoder and ffmpeg. Both didn't work. I was surprised when capturing video at 320x240 with xawtv's streamer, everything was flawless. Considering the lower quality of the SLP-recorded tapes, I thought this workaround was a viable solution.

I tried updating the video4linux kernel module with the Livna repository, but this had no effect. I suspect this problem was caused by the kernel, somehow.

Thanks again!
posted by remi at 5:19 AM on August 17, 2007