While some TBC circuits can make the video look worse, that is the exception. In general, a good TBC can make a massive improvement in the quality of your captures. By comparison, the difference in compression artifacts between codecs, or the ability to change the analog gain by using a proc amp (which, as you are finding out, almost always leads to problems) is roundoff error.
Simply put: TBC = Better Result.
Hopefully most of your tapes are not badly exposed. If so, you just want to capture them in the most efficient way possible. If you make the workflow too complicated, and if you constantly have to be adjusting knobs and dials, you will ALWAYS eventually forget some setting and then probably not catch your mistake for a long time and either have to live with the lousy capture, or else go back and re-do hours and hours of work.
+ Reply to Thread
Results 31 to 49 of 49
Should I use the ES10 between 8mm camcorder and capture device? Or is it mainly just helpful for VHS captures?
I am quite sure that I read somewhere not to use something like an ES-10 unless you try first without it and experience issues. Iím trying my first full 2 hour capture right now with 8mm camcorder. Itís been about 20 min so far and virtualdub isnít reporting any dropped frames yet. I am not quite sure what types of things I would be looking for as far as other issues. If it looks good upon playback after, I assume the ES10 wouldnít be of much use, and could also do some negative things to the video quality (posterization), if what Iíve read is correct.
It's interesting that you mention dropped frames. The only capture system I've ever used that never, even once, gave me a dropped frame, was DV.
As I remember, VirtualDub is not the greatest client to use when capturing, specifically because it was tough to tune to eliminate dropped frames. Others can chime in with advice, should you find you have dropped frames.
I would definitely recommend that you take the middle of one of your first captures, before you get too deep into the project, and put it on the timeline in your NLE. Then, walk through the video frame-by-frame, for a few hundred frames to look for duplicate frames. Dups are easy to spot (I have an AVISYnth script that finds them automatically). Even though you are looking for drops, almost all capture software, when it does drop a frame, will insert a duplicate a few frames later in order to keep the audio in sync. Since looking for the dups is easy, whereas spotting a drop can be tough, even when there is a lot of movement, and near-impossible in low motion scenes, I always look for dups.
As for whether to use a capture system with TBC somewhere in the chain, I already answered that: it is almost always better. The only reason I insert "almost" is that some TBC circuits are actually quite poor. Lordsmurf has some details about this over at DigitalFAQ.com.
Rather than capturing hours of video before you get your capture chain perfected, if I were you, I'd be doing all sorts of 30 second capture test, using various permutations and combinations of the hardware and software you have.
With using the code above with my input as an AVS file that includes QTGMC in "slower" mode (with the source file within the AVS script being my huffYUV original capture) what kind of speeds should I be expecting to see in the cmd window as ffmpeg is processing all of this? I'm showing 0.217x and fps=13. This seems slow but I have no point of comparison so it might be normal - I suspect this will take a long time for a long video. Is there a way to interpret the .217x to know about how long the encode will take compared to length of video? (Is 1.0X basically in real time?) I'm on a core i5 windows 7 desktop and I included some code in my AVS script to tell it how many cores, processors, threads to use etc, and I want to make sure I didn't screw that up. My CPU usage is only at 65-75% so I'm suspecting that I did. I was expecting CPU usage to be near 100%.
Regarding interlaced filtering, most interlace aware filters do something like AviSynth's
SeparateFields() Filter() Weave()
0 1 2 3 4 ... 476 477 478 479
0 2 4 ... 476 478
1 3 ... 477 479
[Attachment 54765 - Click to enlarge]
Be sure to view the image full size. On the left is the original video, in the middle is the result of Blur(1.0), on the right is the result of SeparateFields().Blur(1.0).Weave(). Notice the ugly artifacts of the latter?
A similar problem occurs with temporal filters. Notice how scan line 0 is now in the same vertical position as scan line 1, 2 is in the same position as 3, etc. Any temporal filter now also has information crossing from even to odd scalines.
Another way interlace aware filters can work is by separating the fields, filtering all the even fields separately from the odd fields, then weaving them back together:
SeparateFields() even = SelectEven().Filter() odd = SelectOdd.Filter() Interleave(even, odd) Weave()
Jagabo- thank you again for the very detailed reply and the links to the older threads. I read through all and it definitely helps.
I did my first capture without the ES10 and to my untrained eye I donít see any blaring issues. No wavy lines or edges, no dropped frames and no audio sync issues. I canít right now but maybe early next week Iíll post a short sample from that capture and you can tell me if you see any of the tell tale signs that a TBC is needed or would help.
For now, the main issue I seem to be having is that the video just looks dull. It lacks depth and pop, even for an old home movie, and even when compared with the old DV capture which seems more vibrant in comparison with zero color correction or levels processing.
I tried playing around with levels(), coloryuv() and tweak() but canít seem to get it to look how I want. I donít know that I would think it was that bad if I didnít have the DV capture to compare it to, which in theory has a worse color space and would expect opposite results. So it must be something I am doing. (I will say that the finished processed deinterlaced file of the new capture when viewed on my tv shows a MASSIVE improvement in other areas when compared to the DV capture. Much cleaner, clearer, better quality. Itís just the colors and contrast I canít seem to get right.)
I never took my video out of the YUV color space - all edits were done in avisynth and the only conversion I did was to YV12 for QTGMC. Never brought into virtualdub or converted to RGB as far as I know. And then I used Jagaboís sample ffmpeg x264 batch script which specifies color range tv and bt709 (I think, from memory). Do you think my issue is with the proc amp settings during capture that would make colors look washed out? Again, I will post a sample as soon as I can, as Iím sure you canít answer that question without seeing it.
Most capture cards create perfect duplicates, so you can leave the "blankthreshold" value between 0 (perfect dups) and 1. The YDifference values between frames is usually quite high (>10 for sure), so any numbers between 0 and 1 will require that the adjacent frames be virtually identical.
Once you find duplicates, go back and forth on the timeline from each duplicate and I'll bet you detect an abnormal jump in the motion, indicating a dropped frame. As I said in an earlier post, jumps are sometimes very difficult to detect (although you'll sense them when you watch the video, but dups are easy to spot.
#This script finds duplicate frames and outputs the frame numbers loadPlugin("c:\Program Files\AviSynth 2.5\plugins\dgdecode.dll") #Set this number higher to find more "duplicates". Zero finds only perfect dups. global blankthreshold=1 filename = "e:\output_duplicate_frames.txt" AVISource("e:\fs.avi").killaudio() i=AssumeBFF.ConvertToYV12 #This line below will output EVERY frame that is below threshold, which results in LOTS of frames #Normally you don't do this, but it is included for those who want this capability. #WriteFileIf(last, filename, "(YDifferenceFromPrevious(i)<=blankthreshold)", "current_frame+1", append = false) #The line below writes the FIRST frame that falls below the threshold WriteFileIf(last, filename, "(YDifferenceFromPrevious(i)>blankthreshold)&&YDifferenceToNext(i)<=blankthreshold", "current_frame", append = false) #Use this instead of WriteFile in order to determine blankthreshold #ScriptClip("Subtitle(String(YDifferenceFromPrevious(i)))")
[Attachment 54779 - Click to enlarge]
The huffyuv cap has slightly higher black levels and slightly lower white levels. A small ColorYUV(cont_y=20, off_y=2) adjustment to the huffyuv cap makes the levels nearly identical:
[Attachment 54778 - Click to enlarge]
There ares some slight color differences but those could be adjusted too.
Originally Posted by jagabo
I would really like to get the capture as good (i.e. close to source) as possible so I'm not having to try to correct everything afterwards, but I've read not to mess too much with other proc amp settings besides brightness and contrast (and maybe turning sharpening down). Any other tips (besides increasing saturation in proc amp)? Is my too-high black level the cause of the wishy washy colors? PS. The colors actually don't look bad on my monitor, but they look dull on my tv (especially when compared to my original DV conversion, as I mentioned, when viewed on same TV).
A sample from the final converted file I am viewing on my tv is also attached ("8mm_27_1995_03a sample.avc.mp4"). This is after my attempt at corrections on the attached AVI capture with AviSynth and then converting using your sample ffmpeg batch script, which I left basically as-is - coped below.
Side note, any idea why the converted h264/mp4 file after using this batch file will not open in MPEG Streamclip? I was able to use Avidemux to extract the sample, but I tried MPEG Streamclip first and it said it's an unrecognized file type. MPEG Streamclip has no problem opening the mp4 sample I uploaded here, after extracting it with Avidemux, but it won't open the original full-length file. Is there something weird in the header? I attached a media info export of the full-length file that won't open in MPEG Streamclip.
Side note 2, I used your sample ffmpeg batch file almost exactly as you provided it (code I used is below) because I don't know all the necessary settings and flags enough at this point for h264, as I was using Handbrake before. I know you were just providing a sample to show me how to convert via drag and drop, but is this OK to actually use for my conversions? Or are there some settings I should look into in order to better understand my options? I did look up each of the flags you used so I knew what they were doing and it all seemed fine to me, but not sure if there are other flags I should use as well.
"C:\Program Files (x86)\ffmpeg32\bin\ffmpeg.exe" ^ -i %1 ^ -c:v libx264 -preset slow -crf 16 -g 50 ^ -profile:v high -level:v 4.2 -colorspace bt709 -color_range tv ^ -acodec ac3 ^ "%~dpn1.avc.mp4" pause
Last edited by Christina; 7th Sep 2020 at 22:57. Reason: typos, as usual
VirtualDub(2) and select File -> Run Video Analysis Pass. That will execute the script frame by frame as fast as possible.
But in general, this is why I don't like histograms for checking levels -- you don't know what parts of the picture are out of spec. Looking at a waveform monitor of your capture in AviSynth:
[Attachment 54820 - Click to enlarge]
You can see that only the black overscan bars are near y=16 (that's why I was thinking you may have not cropped enough, or the histogram is pre-copping). The part of the picture you care about doesn't have full blacks (and it's not just this frame, the entire clip never approaches full black).
"C:\Program Files (x86)\ffmpeg32\bin\ffmpeg.exe" ^ -i %1 ^ -c:v libx264 -preset slow -crf 16 -g 50 ^ -profile:v high -level:v 4.2 -colorspace smpte170m -color_range tv ^ -acodec aac -b:a 160 ^ "%~dpn1.avc.mp4" pause
I'll touch base again after I try reencoding to see if the wrong colorspace in ffmpeg script was the primary issue with the desaturated colors.
Analog domain proc amps tend to be far better than digital "proc amps" (not really) in capture cards, or post-capture software corrections. Noting that BOTH analog + digital/software are almost always required. Sometimes even capture card proc amp for good measure.
All of the sample images on pg1 are pretty crappy, obvious non-analog correction attempts.
You also need lossless. Starting from DV is like running a race with a broken leg. Won't work, or miserable experience, or both.
ES10/15 adds posterization effects, ie screws with color more than normal.
DV color loss presents as dull, sometimes fuzzy. It is what is is.
Thanks for chiming in. Just showing the [old] DV capture as a point of reference because actually the colors in that capture looked better to me on my tv than my lossless capture, which we know shouldn't be - I'm now capturing lossless with the ATI 600 USB (purchased from you last month). I was having trouble getting the colors and levels right on the lossless capture using the only proc-amp I have, the one built into capture card adjusting in VirtualDub - Jagabo has been helping me understand the histograms and waveforms and I'm experimenting to get as best results as possible. We think the tv color issue on the lossless capture might have been in the ffmpeg script on final conversion but I still have yet to test that out. I have an ES10 in case but haven't even tried it yet since so far I haven't had any wobbly video.
I ran the AVS script in VirtualDub2 to find duplicate frames. It found about 14 or so. I scrubbed to each of them and in 100% of the cases, it was when scenes were switching, i.e. the recording was stopped and started again. So it looks like I had a pretty good result from my capture with no actual dropped frames during normal scenes, as far as I can tell and as far as the script is reporting.
I tested the histogram during capture in VirtualDub as you suggested, cropping off 32 from the sides and 16 from top and bottom and comparing that with the histogram with no cropping, and they're definitely different, so it does seem to take the cropping into account. I attached 4 screenshots here showing the differences. The filenames should be self-explanatory but you should see:
1. histogram with no crop - using proc amp settings from original capture
2. histogram with large crops - using proc amp settings from original capture
3. histogram with large crops - adjusting brightness down by 2 (from original capture settings)
4. histogram with large crops - adjusting brightness down by 4 (from original capture settings)
I tried to keep using the same part of the video by rewinding each time but certain parts of the video showed blacks just starting to clip while others seemed ok with the lower brightness setting at 118.
With brightness lowered by 4 to 118 (which does show some slight blacks clipping in VirtualDub histogram with 32/16 cropping as in screenshots here) I recaptured the same part of the video we've been looking at, disabling the cropping for the actual capture. I checked waveform in AviSynth and it still doesn't look like it changed all that much- still a pretty big gap of space at the bottom. I attached the waveform here as well. I don't know how much lower I should go, being that I'm already seeing some red at this level. Do I make it even lower and increase the contrast even more? At what point is this just going to make my overall video too dark at the expense of trying to makes the blacks truly black?
Part of this issue may also be illegal blacks. What is referred to as "blacker than black" ("crushed blacks"), and falls in the non-YUV 0-15 range. What some refer to as "clipping black", but that term has a negative connotation that seemingly blames the card. But the card is correct, the video input is not. (I think "clipped black" is a photo term that has leaked into video.) Certain cards, namely ATI AIW, can capture those sub-blacks. The ATI 600 USB is an excellent card, but it's "normal" in this regard, capturing only the legal 16-235 values.
The solution for this is to properly adjust the video with a proc amp.
Understand that this mostly happens on underexposure, and the data tends to be lost no matter if 0-255 RGB or 16-235 YUV. VHS was analog, not digital, so it didn't always precisely record in the equivalent 16-235 range. Some tapes are too dark, other too light.