VIdeo Flicker when walking while filming

[drumlin]

I am new to this forum, so please forgive any errors in protocols.
I also searched the forums to see if anyone had similar issues, but I did not find it.
I have a number of 8mm video cassettes that I am trying to digitize.
I am using an old Sony Video Camera Model CCD-TRV112.
My computer (Linux Fedora 33) has an old Hauppauge WinTV PVR 150 Video Capture card to digitize the analog output.
The software I used is MythTV.
I don't think I have a general problem - I can digitize the video OK.
The problem I have is with scenes where I am walking with the camera while filming.
The result is a flicker in the digitized video.
The Sony camcorder has a little screen to view the video, and I don't see this effect on this screen.
I also don't recall seeing this when we were viewing these on our old analog TVs (many years ago).
This seems to be a phenomenon in the digitization process.
I've tried various settings when capturing, with no luck.
I am beginning to think there may be some limitation in the hardware - my capture card?
Has anyone seen this before?
Or, does anyone have any recommendations on any other capture device to use that would avoid this problem?
I will attempt to upload a sample.

[DB83]

Logic would suggest that these are time-base errors which only occur at the digitizing stage but.......


these errors should also occur during steady/non-walking sequences.


Which indeed leads me to the hardware ie capture-card. This is a legacy device which I suspect only had drivers for Windows and no such drivers beyond WinXP - certainly my own PCI slot WinTV card is not supported after that. So how can this even work under Linux ?. That it does the software could well struggle with the extra information sent for digitizing for the movement and there is some severe pixelation also present.


I can not suggest any current device for Linux unless that OS indeed can make use of Windows drivers and that being so the same issue may prevail.


Just my own opinion. Others may beg to differ.

[drumlin]

Thank you for the reply!
Sorry, but I forgot to mention the driver, which is ivtv.
There is actually much online information on using MythTv with Hauppauge video cards.
I am guessing the driver is not an officially supported driver.
I would consider other capture devices, and even windoze capture devices, but in that case, only as a last resort.
Thanks!

[oln]

It is time-base errors, the capture card loses track of the non-visible parts of the video signal that tells where a frame starts etc. Recording when moving around would cause the video tracks being recorded to be a bit less stable, for a TV it's no issue but these capture cards lose track easily.

Solutions have been discussed countless times on these forums, a higher end Hi8 camera (newer Sony Hi8 and Digital8 cameras are the ones most commonly used) that feature a built-in TBC would help. Passing the video through certain models of dvd-recorder, like Panasonic ES10/ES15 and similar (or a TBC unit but those are expensive and hard to come by) will also help.

A lot of capture cards, especially older ones based on common chip configurations like this one are supported out of the box in Linux.

[drumlin]

Thanks for the reply!
So I guess I know what the problem most likely is.
I've started reading about time based corrections, and what to do about it.
You are correct, there is a lot of discussion.
However, there is one thing I'm confused about and this may be a stupid question.
As I originally mentioned - I do not see this problem on the little monitor of my camcorder.
How is this being corrected?
Maybe I am not understanding this (yet).
It seems a potential solution is another device (TBC) that receives my analog signal before I try to capture again.
How is this guaranteed to work?
From my simplistic point of view, I already seem to have a good video that I am viewing from this monitor?
I will continue reading.
Thanks!

[Eric-jan]

However, there is one thing I'm confused about and this may be a stupid question.
As I originally mentioned - I do not see this problem on the little monitor of my camcorder.
How is this being corrected?

Not a stupid question.... it's not corrected, the other hardware is just more forgiving, a capture device just needs a very stable (analog) signal, like it came directly from a live camera, or live broadcast by a tuner/reciever, the analog recorder device is a mechanical device, the headdrum which is putting the signal onto the tape, will have a slightly deviaton when the camera is moved or bumped, this is "baked" into the recording, and has to be straightent, an image is made out of stacked lines, will have 2 fields of lines interlaced into eachother making one frame, there are signals that tells if there has one line ended and a next one comes, if one field is complete, a signal tells the next field is coming, a signal tells one frame is complete, and should disapear (blanked?) and so on.... maybe i do not have this exactly right, but that's the general idea, so .... anything can go wrong while this is happening, but the hardware player is just more forgiving, and the correct TBC will straighten this, before it goes into the capture device.

(when vcr's "came into the picture" i remember even the tv sets of that time needed correction for the signal of the vcr, the original broadcasts were fine, but watching a recording from the vcr, had the top part of the image slanted, newer tv sets where already adjusted for that.)

A cheap way to replace a TBC is to try out some passthrough devices, like DVD-recorders found at the thrift store/shop, some cheap converters might work, but that is more mis than hit and will reduce quality, which leaves a DVD-recorder as a reasonable option, also experimenting with the settings of that device an VCR with build in TBC is also helping, but results might be various, due to age or device make (chipset) JVC, Panasonic, or Toshiba, are good bets.
But there is already a lot of information about that available here, and elsewhere.

[drumlin]

Thank you for the reply and information!
It seems all these replies have helped me to understand the problem a little better - so thanks to everyone!
You are correct that there is a lot of information out there and I am slowly sifting through a lot of it.
It seems that when I get to some suggested solutions, I look around online for the suggested hardware, and if it is still available, it costs lots of money.
I think my last set of questions were more of wondering if it is worth spending $1000 for something that I am not sure would work to correct the time based errors.
It seems like it should work.
I also forgot to mention (since it was a few months ago that I started playing around with this) that in my first iteration I was using a Sanyo VWM-690 VCR.
The front had some AV inputs that I connected with the Sony camcorder.
Then I connected the VCR output to the Hauppauge capture device.
So whether I went directly from the camcorder to the capture card or through the VCR, the result was the same.
I just checked the VCR manual to see if there is any mention of TBC and there wasn't.
I also have a Sony SLV X317PS multi-system VCR, and again the manual makes no mention of TBC.
I'll keep reading and looking around for any hardware that is available.

[DB83]

Well you should not have to pay $1000 for a Panasonic ES10/15


For the sake of clarity these work in pass-through mode. You feed you video from the original source through the Panny to the capture device.


These work at field level and that should be sufficient for time-base correction.


No vcrs, AFAIK, perform this.


Most stand-alone TBC's you see for sale are full-frame devices. They should also work but tend to be more expensive than pass-through devices (DV camcorders can also perform this function). As mentioned, all relevant info has been discussed many times.


I still stand by my original remarks since pixilation( or to be more accurate in this case total loss of pixels) is not a feature of time-base errors but then a weak signal can cause all sorts of issues.

[dellsam34]

These work at field level and that should be sufficient for time-base correction.


No vcrs, AFAIK, perform this.

Correct, However I believe if he will to use a Hi8/D8 camcorder with line TBC he will get a much cleaner signal and his capture card will lock onto the signal. Not all capture cards can work with composite signal, that's why S-Video is much more stable especially if line time based.

I still stand by my original remarks since pixilation( or to be more accurate in this case total loss of pixels) is not a feature of time-base errors but then a weak signal can cause all sorts of issues.

I see two problems in that sample, One: frame loss due to the capture card not locking on the VBI signal from the tape and I blame that on both the camcorder and the capture card, Two: frame tearing, the capture software is struggling to lock on the frame rate supplied by the ADC chip inside the capture card and that could be the capture card chipset to blame.

So I agree an ES10/15 could fix all but a good player is another alternative if it's cheaper or at the same price. Ideally both.

[drumlin]

Thank you for the recent replies!
As mentioned before, there certainly is a lot of information that has been discussed.
Unfortunately, I've not had too much time to process it all, and separate the wheat from the chaff!
There also doesn't seem to be a unanimous opinion here in the few replies that what I am seeing is a time based error.
I also am not opposed to spending as little money as possible for a solution, so I would not mind trying an inexpensive vcr with pass-through tbc.
However, in some of the information I've read, some people do not consider these devices true tbc devices.
Perhaps, they will work for my particular issue, so I am willing to give it a try.
Thanks again for the time taken to look at my issue and offer suggestions!
I will continue to read up on tbc (there's a lot to digest) and would appreciate any additional feedback!
Thanks!

[drumlin]

I had been meaning to post a follow-up to my thread, and didn't manage to do it earlier, so I apologize to all the people who helped me with this problem.
What I did was look through some old posts and noticed someone else had the same exact problem as I did: https://forum.videohelp.com/threads/399169-Flickering-bouncing-effect-while-grabbing-s...-Video8http://.
So I went to eBay and bought a second-hand Panasonic DMR-ES15 and used it to pass through my signal to my capture device.
The result is a much improved video, and I am attaching a clip for comparison to my earlier attachment.
Again, thanks to all the suggestions and help!
I hope this will help other people as well.

[Eric-jan]

That looks good ! the only next better thing would be using the component video output this DMR-ES15 has, you would also need a capture device with component video input, the advantage would be that you can set the component video output in progresive mode, this works realy well with the DMR-ES35V that i have, (a combo recorder which already has a VHS deck)
With movement in the image of your sample there's still some effect of de-interlace, which is not smoothed out….. you could also get a slightly sharper picture out of the component vdeo output, if you could use that with the right video capture device, composite and s-video give not an optimal picture performance.
The other tip using a Digital8 player is also an option, but ideal would be that you do the transfer over a iLink/Firewire connection, your computer should have a Firewire connection, or you should find a Firewire interface card for your PC, in theory you loose an amount of colors, but i doubt if the human eye will notice this, the software needs an option to transfer the data from the Firewire port, this could also be a problem in some cases, the option of OBS software is not a good one, because it captures (again) from your screen…..
btw. that DMR-ES15 is a good catch ! you will have much profit of that one ! if you want to do more capture work in the future, look into the video component output option, something better than that, there isn't, it's signal is clean, and Macrovision is not present at this output if it comes from another vcr, that's the way the ES35V works for me.
btw. i see you're on Linux, using Firewire in this OS should not be a problem i guess, there's a good comunity that can help you with this, and a driver for Firewire should not be a problem, i think, and Linux is a solid OS to do capturing on. on a certain Linux distro you can even run Davinci Resolve, with the hardware that will support it.

[drumlin]

Thank you for the information!
Yes, I am using Linux (described in my original post, maybe not too well), but I do not have any firewire ports on my computer nor capture device (also described in my original post).
It's also been a while since I converted my tapes, but I now have another batch to do.
So I double checked my connections, and I am using the component video output.
I now vaguely recall that I could not get the coax output to work for some reason.
I should also mention that the video clip is not the raw output from my device.
I have blank output (time between starting capture and starting vcr) before and after, so I used openshot software to clip the beginning and end.
Then I export the video, so maybe something is wrong in my setting.
I'll take a look at that.
Thanks again for the comments!

[Eric-jan]

You're not mixing up composite and component video ? composite = yellow. component = red,green,blue, s-video=mini DIN connection

if you do use component, look for progressive settings both in the E15 and the capture card settings, and when you can set both in those exact settings, you can judge for yourself if this gives better results, compaired to capturing in interlaced mode, de-interlacing with software in post, can take a long time, plus there are a lot of de-interlace options to choose from, and which wil give best results, capturing straight in progressive works for me, but capture software should support it, and i only have one option available here, which works also.

[oln]

That card doesn't have component inputs at least. I don't think there would really be a noticeable difference between S-Video and component for this use case though, especially since it's NTSC (using composite, i,e single RCA cable for video, or antenna cable will look worse though) So, I would just use S-Video between the ES15 and capture card. There isn't really much advantage to letting the ES15 deinterlace (other than maybe saving time), it's not going to do any better than doing it in software with a decent deinterlacer.

[Eric-jan]

I only know it saves me some work in post, i only color correct/color grade in post, and do some samples to check quality/compression ratio, on the scenes with most movement in the image,
i do have the advantage the ES35V having a VHS deck, and i do see some improvement using YUV for capturing, over s-video or composite when comparing, only disadvantage is you need a capture device that has component video input, which most people don't have, or don't know how to use it.
an other advantage of working on MAC is using the ProRes codec during capture, ProRes is good enough for VHS quality, depending your hardware you can try which "grade" of ProRes codec to use, i guess the Linux OS will also have a good choice of codecs to use. (better than on Windows is my guess)

[drumlin]

Thank you all again for the comments.
Yes, I think I was confusing component and composite, and it is true that the card does not have component input but it does indeed have s-video.
I also did not notice the interlace issue, since I viewed the video on VLC which was set to automatically de-interlace.
I will try de-interlacing with the software I have - openshot or shotcut.
Thanks!

[Eric-jan]

I guess if you play the file(s) not on a hardware media player it doesn't matter, So it's because you can't change the setting on the hardware player, it's because that it's converted for a LCD/TFT display, on a CRT it's okay to leave it interlaced.
an up to date VLC software player does not need external codecs to play video files.
But you will have no problems with drivers on Linux, because the update process is easy and will give no conflict with other software on the OS, unlike Window$ sometimes….
Shotcut is also a nice option with much things to set in detail, but sometimes i loose "my way" through the complexity of it, and it also will let you make videos that are not compatible with any player..