Is it worth it recapturing videos?

[Alwyn]

Looking good, Riker!

I would consider Sharc's comment and reduce the Contrast in the Proc Amp )Device Settings) to 100 to see if you get better-balanced levels (still look just a bit too bright to me).

But independent from the current case I agree that the brights are slightly too high for the I-O Data GV-USB2. Using reference patterns I have to step the proc-amp contrast about 5 steps back from default (105->100) to capture reference white at Y=235 and reference black at Y=16 if I want to capture "spot on". At least for my setup.

[Sharc]

Yep. Basically correct.
You may have noticed the ugly scene change glitch at frame 173 or 285 respectively. I would just remove this frame in post processing.
Of course you loose 50% of the motion with the 29.97 deinterlaced variant.
The 59.94 variant preserves the full motion but has duplicate frames (53,54), (124,125), (195,196), (266,267), (337,338), (408,409), (479,480), (551,552) causing temporary slight stutter during playback every ~71th frame. You may address these in post processing as well. I didn't spot any obvious dropped frames in my quick test.

[Alwyn]

Those duplicates don't exist in the 29.97 version. QTGMC shouldn't introduce them, I don't believe.

Can you attach the original capture, before you converted it to ProRes?

[Riker0007]

https://files.videohelp.com/u/139455/raw.mov



Curious on how/what you are able to see these frames that are not good?

Thanks you both again for your help!

[Alwyn]

Your capture workflow has a bug. As I mentioned before, this is the frame rate of your raw captures:

Frame rate mode : Variable
Frame rate : 29.740 FPS
Minimum frame rate : 14.985 FPS
Maximum frame rate : 29.970 FPS

It should be rock-solid on 29.97. This will give you that: VCR>(stabiliser)>GV-USB2>VDub or AmaRecTV>HUFFYUV or UTVideo 29.97 AVI format.

The variable frame rate is possibly causing all those dupes.

[Riker0007]

Your capture workflow has a bug. As I mentioned before, this is the frame rate of your raw captures:

Frame rate mode : Variable
Frame rate : 29.740 FPS
Minimum frame rate : 14.985 FPS
Maximum frame rate : 29.970 FPS

It should be rock-solid on 29.97. This will give you that: VCR>(stabiliser)>GV-USB2>VDub or AmaRecTV>HUFFYUV or UTVideo 29.97 AVI format.

The variable frame rate is possibly causing all those dupes.

That's exactly my flow. JVC 7800u> GV-USB2 >AmaRecTV>UTVideo>29.97 AVI.
The raw.mov file was converted to prores. Maybe that's where it happened? Unfortunae
What am I missing? Is it my settings or driver?
https://files.videohelp.com/u/139455/IMG_7220.JPG
https://files.videohelp.com/u/139455/IMG_7221.JPG
https://files.videohelp.com/u/139455/IMG_7222.JPG

Is the frame rate of the iodata suppose to be doing this with the frame rate changing?
https://files.videohelp.com/u/139455/iodata.avi


I recaptured without converting to prores: This seems to be right. Perhaps it was whatever the script was for converting to prores? I don't have the script anymore that I can find.
https://files.videohelp.com/u/139455/Raw%20no%20prores.avi

At this point, do I just recapture?
Thanks

[Sharc]

@Riker0007:
Both your 'raw.mov' of post#94 and your 'Raw no prores.avi' of post#96 are fine and do not have any duplicates. Framerate is correct and stable, and after QTGMC it delivers 59.94fps progressive frames without duplicates. So all ok it seems.
I strongly believe that this latest 'raw.mov' and 'no prores.avi' are not from the same capture which you have been using for the former 59.94.mov of post#90 with the duplicates, or something else in your workflow has been changed since.

@Alwyn: use a source filter like LWLibavVideoSource and it will return the usual standard framerates. That variable framerate report of MediaInfo has other reasons (trimming, mov timebase) and is just confusing in this context. Maybe add AssumeFPS(30000,1001) or AssumeFPS(60000,1001) to the scripts.

[jagabo]

@Alwyn: use a source filter like LWLibavVideoSource and it will return the usual standard framerates.

Because LSMASH converts incoming VFR to CFR.

That variable framerate report of MediaInfo has other reasons (trimming, mov timebase) and is just confusing in this context.

RAW.MOV from post #94 is VFR. Most frames have timecodes for 29.97 fps. But two are 14.99 fps.

[poisondeathray]

raw.mov and "Raw no prores.avi" are no longer aligned after several field drops . The first one occurs after frame 148 of the AVI and frame 97 of the mov are aligned, after that the mov has a dropped field. There are at least 2 more drops for the mov. In field numbers (or double rate deinterlaced numbers 195-196, 197-198, 265-266) . That 3rd drop is a drop in the original AVI (369-370 field numbers) . So there are drops from original capture, additional drops from converting to prores

Notice raw.mov has a lower fps declared than 29.97 fps ; it 's 29.74 fps and that delta probably represents the additional drops from converting to prores incorrectly . That's probably where the duplicates where inserted when converting to 59.94 later ( instead of 59.48 - a "ChangeFPS" type conversion where frames are inserted or dropped to hit the target framrate; or a VFR => CFR onversion)

[Riker0007]

Is there a fix? Do I just have to recapture?
What do I need to do?
Thanks

[poisondeathray]

It's up to you ; but something is definitely wrong with your prores conversion process because additional, avoidable errors are introduced - I'd review that workflow

You also want to assess what effect the additional drops are having on AV sync, especially after a long period . Is audio dropped as well ? Is there async ? etc...

[Sharc]

Because LSMASH converts incoming VFR to CFR.

Ah, I see, thanks. And it does it like Avisynth's ChangeFPS by means of dropping/inserting frames or by means of timecode adjustments? And for a .mov VFR clip of longer duration but with few timecodes only deviating from nominal these drops/inserts would occur less frequently? The 2 odd timecodes of 14.99 are due to the trimming of a short sample clip or due to a capture problem of the .avi, or due to a flawed conversion to ProRes .mov? Hmm ....

Edit: Post#99 of pdr suggests that several issues are probably "distributed" along the workflow.

[Riker0007]

Gonna recapture the tapes.
Does any of this have to do with the need for a full TBC?
Also, does anyone see any thing about the captures that would indicate the need to clean the video heads?

Thanks to all, I've learned a lot and clearly need more!

[Sharc]

@Riker0007: Keep in mind that converting the interlaced .avi versus converting the deinterlaced version to ProRes requires a different ffmpeg commandline for the conversion.
Perhaps the reason why your conversion to ProRes introduced additional drops (?). Just a thought......

[jagabo]

Because LSMASH converts incoming VFR to CFR.

Ah, I see, thanks.

Oops. I remembered incorrectly. It doesn't convert VFR to CFR by default, you have to specify if you want CFR (via the fpsnum and fpsden settings). I was thinking of MPEG2 -- where it performs soft pulldown automatically.

And it does it like Avisynth's ChangeFPS by means of dropping/inserting frames or by means of timecode adjustments?

Yes, when it does convert to CFR it just drops/inserts frames as necessary.

[Alwyn]

Gonna recapture the tapes.

Provided you've still got the AVIs in UTVideo codec such as your "raw no prores.avi" in post #96, I don't see a need.

Those AmaRecTV settings and IOData driver are fine.

The problems are being caused by the conversion from AVI to ProRes.

Does any of this have to do with the need for a full TBC?

I doubt it. The video image is nice and stable. Check a long capture for audio sync; if it's in sync, you should be OK. If anything, you could put an ES-15 or similar stabiliser in the capture workflow.

Also, does anyone see any thing about the captures that would indicate the need to clean the video heads?

Not at the moment.

[Sharc]

Provided you've still got the AVIs in UTVideo codec such as your "raw no prores.avi" in post #96, I don't see a need.

Those AmaRecTV settings and IOData driver are fine.

The problems are being caused by the conversion from AVI to ProRes.

Agree. He has to revisit his deinterlacing and conversion steps. I don't get any additional drops or inserts when converting his 'Raw no prores.avi' to Prores properly. I tested interlaced and deinterlaced variants. The frames and fields sequence remain identical. No extra drops or inserts are introduced by the conversion from .avi to ProRes. It is a 1:1 mapping, including the glitch.

[Sharc]

@Riker0007:
In case you have issues with Avisynth you can skip Avisynth and do the double rate deinterlacing and conversion of your captures alltogether in ffmpeg instead, using the commadline like

ffmpeg.exe -i "Raw no prores.avi" -c:a copy -c:v prores_ks -profile:v 3 -vendor apl0 -bits_per_mb 8000 -pix_fmt yuv422p10le -vf bwdif=mode=1,setsar=10/11 "proRes422_deint.mov"

You may want to try this as an alternative to involving Avisynth.

[Riker0007]

So I got a Panasonic DMR-ES15 today and here is what I captured. I tried uploading a one min clip of both, but I kept getting a verification error so these are the cut down versions to about 20 seconds each. I've also included the original capture logs from the iodata unit.

This one is with my JVC 7800u only
https://files.videohelp.com/u/139455/jvc%20only.avi
https://files.videohelp.com/u/139455/JVC%20only.txt

This one is running the JVC into the DMR-ES15 as pass through.
https://files.videohelp.com/u/139455/jvc%20w%20pass.avi
https://files.videohelp.com/u/139455/JVC%20with%20Pass.txt

[Alwyn]

Excellent.

A classic example of the killer stabilisation of the ES-15. The "JVC-only" has lots of duplicated frames (check the "total" number (53) at the bottom of the AmaRecTV report) whereas the JVC+ES-15 has none (ignoring the 3 at the very start as the recording starts).

Assuming, of course, the TBC in the 7800 was On, in the 'JVC-only" test?

You can see the dupes if you open the file in VDub and then use the Shift+] keys to go to the next "dropped" frame (not really a "drop", a dupe).

Of interest also is the almost perfect match, image quality-wise, between the two, putting paid to the doom and gloom espoused by some that the ES-15 destroys the image. And the levels are almost perfectly matched, putting paid to the other myth that the ES-15 is too bright. Would a $2000 TBC produce a significantly better image? Who knows.

Yes, the forum only takes 500mb max, so around 30 seconds results in a good file size.

[Sharc]

The JVC only is very poor: drops and duplicates and field swaps ..... (Did you have the TBC switched "ON"?)
The JVC w pass is much better in this respect, but still has some annoying vertical instabilities e.g. around frames 238, 260, 1235. You would probably have to address these with a true frame TBC, or fix it in post processing.

P.S. With the ES-15 in place it is usually better to switch the TBC of the JVC "OFF", so you have only one (either....or) TBC in the loop.

[rgr]

That's exactly my flow. JVC 7800u> GV-USB2 >AmaRecTV>UTVideo>29.97 AVI.

How did you convert to ProRes?

[rgr]

Gonna recapture the tapes.

1. Use VDub instead of AmarecTV -- Amarec always drops frames (silently).
2. Convert to ProRes using AviSynth and, if necessary (VFR), http://avisynth.nl/index.php/TimecodeFPS. But if you want to process it later with AviSynth or Resolve you can compress it to H264/H265 lossless 8bit (or with low CRF).

[Sharc]

Gonna recapture the tapes.

1. Use VDub instead of AmarecTV -- Amarec always drops frames (silently).

That's the same misleading general statement as saying "Vdub always produces A/V sync issues", IMO.

[Alwyn]

Amarec always drops frames (silently)

Where are the dropped frames in the files in #109?

@Riker, how's the attached VDub2-converted ProRes MOV open in Resolve (you'll need to reshape it to 4:3). For the avoidance of doubt, I trimmed off the first few frames where the 3 dupes were (all reported by AmaRecTV).

[rgr]

Gonna recapture the tapes.

1. Use VDub instead of AmarecTV -- Amarec always drops frames (silently).

That's the same misleading general statement as saying "Vdub always produces A/V sync issues", IMO.

Tested, confirmed.

Amarec always drops frames (silently)

Where are the dropped frames in the files in #109?

Sample too short. But it's probably enough to capture the tape once with AmarecTV and a second time with VDub and compare.

[Sharc]

Amarec always drops frames (silently)

Where are the dropped frames in the files in #109?

For interlaced captures one would have to look for dropped fields rather than speculate on woven frames. Look for example the messy fields sequence 170 ....220 of the 'jvc only.avi'. For this capture I have my doubts anyway. Hard to believe that the JVC or Amarec alone can be blamed for this mess.

[Alwyn]

As the gee gee goes behind jump 2, you can see the bottom of the tape goes pearshaped. Damaged, I reckon.

Tested, confirmed.

You mean YOUR tests.

[Alwyn]

I'm sure I've never noticed it prior to looking at Riker's videos, but why does the field order reverse at those duplicates? Both QTGMC and VDub's double-rate deinterlacer set off that reversal.

[Sharc]

I'm sure I've never noticed it prior to looking at Riker's videos, but why does the field order reverse at those duplicates? Both QTGMC and VDub's double-rate deinterlacer set off that reversal.

Dropped fields break the regular sequence:
Regular (woven): ....|tb|tb|tb|tb|tb|tb|tb|.....
with drop (re-woven): ....|tb|tb|bt|bt|bt|bt|..... (3rd t is dropped)

The double rate deinterlacer reconstructs the missing field of every field and makes a frame of every field, so one gets a missing frame.
The dropped field - if noticed by the SW - gets compensated later as an inserted duplicate to keep A/V in sync (or a next field drop will restore the original sequence)

Similar when we start with an inserted field. It is just a next field in the sequence and not marked as top or bottom. Depending on the previous field it may become a 't' or a 'b' field after weaving and hence introduce a shift to the original regular fields sequence.

My best guessing, maybe I am wrong.

Added:
Maybe better take a look here re. fields, field dominance, edits etc. (one can consider drops and inserts as kind of edits)
https://lurkertech.com/lg/fields/#howtointerleave