The old "war of opinion" - Capture 8mm tapes in DV or lossless?

[Alwyn]

Would that be worth a try

If you're into "trying things", have a look at the Startech USB3HDCAP. It captures Composite, S-Video, Component and HDMI. Because it's a legit HDMI capture device, its been designed to respect HDCP and it will not accept HDMI signals from the Panasonic DVD boxes, even if the source is a VCR playing home videos. You have to use a splitter to permit HDMI capture. VDub and Amarec both happily capture Uncompressed or Lossless from it.

Startech has it's own software but it has no AVI options, only H264.

As I've said before, the quality of the HDMI capture compared to the more conventional S-Video route is nothing marvellous.

[Marvolo]

Yes, I was involved in the testing.
When that capture procedure was developed and tested – it was 2013 – there were indeed pretty much no other options for ingesting HDMI video into a computer losslessly other than the Blackmagic Intensity Pro (PCIe) and the Blackmagic Intensity Shuttle (USB 3).
But of course any capture device able to do that is fine for the job, and there are more options today.

I don't particularly agree with the VCR recommendations of that guide as well, but that was not the main focus of it anyways.

Thanks for chiming in and helping clarify things.
By the way, Skiller, your guide does not address the here encountered issue of "dropped frames" / "drops". Were you not aware of this or did you simply not include it in the tests? How could I solve this problem??

there were indeed pretty much no other options for ingesting HDMI video into a computer losslessly other than the Blackmagic Intensity Pro (PCIe) and the Blackmagic Intensity Shuttle (USB 3).
But of course any capture device able to do that is fine for the job, and there are more options today.

So, I assume, the main and most essential part about this whole set-up is capturing losslessly - be it with the Blackmagic or any other "grabber" / "usb-device". It's not really about terminology and what / how we name things, but about lossless capture.

The Hauppage mentioned above, according to @lollo, does not capture losslessly.

[johnmeyer]

John, I wholeheartedly agree with you, on the "grabber" and "card". For that reason I use the term digitiser.

I like that!

[johnmeyer]

and I have all the accessories so I can capture from HDMI

Would that be worth a try instead of the Blackmagic Card I'm using at the moment? Or wouldn't it basically make any difference as both devices simply record a (already) digitial stream?

No, it will not capture lossless/uncompressed, but encodes to h264 on the fly by hardware

Yes, Lollo is correct: my device only captures to H.264, not lossless. You can set the compression quality to maximum, but I don't think, based on the resulting file size, that it is anything close to lossless.

[Marvolo]

I don't particularly agree with the VCR recommendations of that guide as well,

Well, luckily they have compensated for that by now and have released a guide that deals solely with this issue: Overview of all both amateur & (semi-)professional JVC & Panasonic SVHS video recorders up to the early 2000s (Thanks to @Bogilein)

[Brad]

If you're into "trying things", have a look at the Startech USB3HDCAP. It captures Composite, S-Video, Component and HDMI.

Note that in my testing (linked earlier) the USB3HDCAP does not losslessly pass YCbCr 4:2:2 from input to file.

https://forum.videohelp.com/threads/376473-Lossless-HDMI-capture-devices-comparison-screenshots

It's subtle, but this is one reason I respectfully disagree with the suggestion by some that we call a transfer from HDMI (or SDI) something other than a "capture".

It's not just a bit-transfer from port to file like a FireWire "data copy" is. Unlike a DV/HDV/D-VHS bitstream, the video can be molested by a driver Proc Amp control, a silent YCbCr>RGB>YCbCr conversion, internal scaling, an A>D>A step... I've also found HDMI capture devices that don't do a 1:1 transfer of audio even when the input and output are both set to 2ch 48kHz 16-bit.

[lollo]

It's not just a bit-transfer from port to file like a FireWire "data copy" is.

I agree. HDMI capture is a "capture", not a copy of a digital stream.

But in the case of the source being an analog signal, it is a good option.

I do not use a HDMI "capture" other than for recording DVB-S channels where the usage of a legal CAM to "dump" the original stream is not possible because the marriage between the Smart Card and the Set Top Box. And I can see the difference between the "dump" of the broadcasted stream (bit-to-bit copy) and the capture of it through a HDMI route, even if this last stays in the digital domain.

[Sharc]

.... the video can be molested by a driver Proc Amp control, a silent YCbCr>RGB>YCbCr conversion, internal scaling, an A>D>A step...

Exactly. That's where a lot of the subtle differences and silent losses come from. The devices and tools usually don't warn from internal 'intermediate' color space conversions with possible gamut violations. The risk is always that extra losses are being introduced when one does not have full control on the levels and conversion algos (matrices etc.) at every stage. AD/DA conversions may be the least critical components even.

[Skiller]

By the way, Skiller, your guide does not address the here encountered issue of "dropped frames" / "drops". Were you not aware of this or did you simply not include it in the tests? How could I solve this problem??

Dropped frames are handled internally by the Panasonic DVD/HDD recorder and there is no way of having them reported. In my experience it only ever droppes frames or fields if they are badly damaged, and to keep audio in sync, thus any loss there is inevitable anyways and therefore OK.

Dropped or inserted frames after the Panasonic, on the computer side of things, need to be zero. VirtualDub works fine and reports those frame drops/inserts.

If you use VirtualDub 1.9.11 do you have frame drops/inserts?

[Marvolo]

If you use VirtualDub 1.9.11 do you have frame drops/inserts?

I have not yet been able to get any version of VirtualDub to run with my Blackmagic Intensity Pro. No matter if I choose the Decklink or WDM driver, I can't get an incoming signal in VirtualDub. Not even in my NLE. It has only worked with the Blackmagic Express Software so far. Any tips to get it running in Virtual Dub?

Some members on here have reported drops or dropped fields in my footage, recorded with the BM Epress Software (see older posts and video samples on here). How do they come about then? Is it the BM software?

[lordsmurf]

AD/DA conversions may be the least critical components even.

Quote worthy.

As I implied earlier, A<>D is not the bogeyman some make it out to be. Damage tends to be incurred elsewhere, and wrongly blamed on A<>D. (The same is true of proper colorspace conversions. Keyword there = proper.)

[Sharc]

I then captured a tape again, hoping this time it won't have created missing frames. I'd still need a reliable way to check for that though. Surely, I can't go through a 90 mins capture and compare every single frame manually by comparing it to the DV reference.

In case you have not seen it: Here a discussion with links you may want to follow, study and digest:
https://forum.videohelp.com/threads/410142-Dropped-frames-How-to-create-a-log

[Skiller]

I have not yet been able to get any version of VirtualDub to run with my Blackmagic Intensity Pro.

With the Intensity Pro, expected video format and actual video format need to match, otherwise you get no picture silently. Sometimes the input format setting reverts back to it's default 1080i for no apparent reason. I used to first start MediaExpress to make sure I get a picture (and change the setting back to PAL if needed), close MediaExpress and then start VirtualDub.


Also check your BM control panel settings. They should look like this:


[Attachment 72230 - Click to enlarge]

[johnmeyer]

@JohnMeyer

As promised, here is a sequence of our ski holiday trip in 1996 in Austria. It's about 1 minute long. I captured - as usual - uncompressed then converted it using VDub into FFMPG Huffyuf 4:2:2, no RGB.
Like I said in my prior post - watching the capture in my preview monitor I can never see any abnormalties such as dropped frames or anything else.

PS: since the file size exceeded the maximum file size of the forum by only 5 mb, I uploaded it on WeTransfer: https://we.tl/t-XGcTx2ulOl

Because of the holiday here in the states, I didn't get to this until today.

I looked at the video very carefully, both frame-by-frame and then field-by-field.

I found no drops and no dups.

I can't fix what isn't broken.

[poisondeathray]

@JohnMeyer

As promised, here is a sequence of our ski holiday trip in 1996 in Austria. It's about 1 minute long. I captured - as usual - uncompressed then converted it using VDub into FFMPG Huffyuf 4:2:2, no RGB.
Like I said in my prior post - watching the capture in my preview monitor I can never see any abnormalties such as dropped frames or anything else.

PS: since the file size exceeded the maximum file size of the forum by only 5 mb, I uploaded it on WeTransfer: https://we.tl/t-XGcTx2ulOl

Because of the holiday here in the states, I didn't get to this until today.

I looked at the video very carefully, both frame-by-frame and then field-by-field.

I found no drops and no dups.

I can't fix what isn't broken.

There is a drop between field 7 and 8 , without an inserted compensatory duplicate field this time

You "fix" it by recapturing

RE: Skiurlaub

There is a drop between field 7 and 8 for FFVH . This time there is no compensatory duplicate field inserted

Hmmm, I can't identify a missed field there. And the FFVH and DV seem to be the same with respect to the captured fields (apart from field parity).
How did you arrive at this conclusion?

Look closely , while separating the Fields . There is a small jump between field 7 and 8

FFVideoSource("Skiurlaub 1996_huffyuf.avi")
AssumeTFF().SeparateFields()

Another clue is the color of the fields. Notice the hue of the fields alternate, blue, magenta, blue, magenta... as you step through. Go through later in the video also to see the pattern . Use histogram("levels") if you cannot "see" it. Notice the "U" channel histogram goes left,right,left,right as you step through the fields. 7 and 8 do not, they have the same offset hue mg color , because there is a missing "7.5"

You can also compare to the DV version (it happens to not have a drop in this case, but don't always assume so) . Field 8 in the DV version is missing point in time from the FFVH version

[Marvolo]

@John

Now that's rather interesting... Especially since "poisondeathray" seems to have found a drop:

There is a drop between field 7 and 8 for FFVH . This time there is no compensatory duplicate field inserted

If the mechanism dropped a field, then always inserted a compensatory duplicate, the field count would be the same between DV and "lossless" capture. (They would line up at the beginning and end in your NLE, but could differ in the middle)

Now who is right?

[poisondeathray]

Now who is right?

This one is easy to miss because the motion is relatively low . A detection script would usually miss this one, because the jump from the dropped frame is relatively small. Or if you adjusted the thresholds to be more sensitive, you'd get so many false positive "hits", that it would be useless as a tool

The field color pattern observation within the FFVH version mentioned earlier is some indirect evidence and a moderate clue, but the definitive "proof" is in the DV version - it has the missing field

This are double rate deinterlaced to 50p with yadif . The frame numbers correspond to the 50p frame numbers (or the original field numbers). The dropped field is inserted from the DV version

It's an animated png, and should animate in most browsers. Open in a new tab if it doesn't animate

So what you are seeing is
FFVH field 7, inserted DV field field 8, FFVH field 8

[johnmeyer]

I saw poisondeathray's earlier post about that drop. My software did report it, but it was so minor that no one is every going to notice it, and I am not convinced it is even a real drop. More to the point, I neither saw, nor did my script report, any other drop in the entire capture.

Nothing is perfect. I'd leave this alone and instead concentrate on the significant chroma variation between even and odd fields, and also the horrible blue cast.

My script did a very nice job of synthesizing an intermediate frame and inserting it at the drop point. Of course it also decimated one of the two most similar frames somewhere within twenty frames of the drop (I think that's the Cycle number I used).

I did run another script which looks for dups (a much easier task) and there are also no obvious dups. This leads me to believe that the "drop" between 7&8 is not a real drop by some artifact from camera movement.

[poisondeathray]

I saw poisondeathray's earlier post about that drop. My software did report it, but it was so minor that no one is every going to notice it,

I noticed it.

Someone that is concerned with "lossless" captures should notice it.

I'd argue that you should always be concerned drops, lossless or not. It's arguably the most important 1st step

"Reporting it" is not a problem. It's when the software is set so sensitive that it reports that small motion as a "drop" it will also pick up 1000's of good frames up as drops - ie too many false positives. It makes the tool less useful.

and I am not convinced it is even a real drop.

This leads me to believe that the "drop" between 7&8 is not a real drop by some artifact from camera movement.

Really ???

For certain that is a drop. Just go field by field. There is a jump in motion

You can see the dropped field from the HFYU video present in the DV video if you align the fields - if that's not 100% proof, I don't know what is .

Nothing is perfect. I'd leave this alone and instead concentrate on the significant chroma variation between even and odd fields, and also the horrible blue cast.

A lossless capture without drops more perfect than one with drops

Sure, you should look at other problems too - but I'd argue you should always start with a proper capture.

Did you read the other part about chroma variation between fields? The observation that there were 2 consecutive fields with the same chroma offset also suggests there is a drop - or is that "some artifact from camera motion too ?"

[johnmeyer]

Did you read the other part about chroma variation between fields? The observation that there were 2 consecutive fields with the same chroma offset also suggests there is a drop - or is that "some artifact from camera motion too ?"

The chroma variation is on EVERY single field: the odd fields have one chroma balance and the even fields have another.

[poisondeathray]

Did you read the other part about chroma variation between fields? The observation that there were 2 consecutive fields with the same chroma offset also suggests there is a drop - or is that "some artifact from camera motion too ?"

The chroma variation is on EVERY single field: the odd fields have one chroma balance and the even fields have another.

Yes, this was pointed out earlier - that's more evidence that there is a drop there if you read the earlier comments and analysis

The pattern breaks between field 7 and 8 . 2 consecutive fields with the same chroma offset because there is a missing field in between them. If you go later in the video the field the pattern is consistent

That , combined with the presence of the missing ffvh field in the DV recording is like 150% proof

Repeat this test, look at the U-channel histogram. Step through the fields. Watch it go left, right, left, right. That's the normal pattern. That doesn't happen between field 7 and 8. Because there is a field drop

ffvideoSource("Skiurlaub 1996_huffyuf.avi")
assumetff().separatefields()
histogram("levels")

[Sharc]

The chroma variation is on EVERY single field: the odd fields have one chroma balance and the even fields have another.

Yes. And a break in the tint pattern as in this clip becomes a problem when one would filter the even or odd fields in order to match the chroma balance between the fields. An unnoticed pattern glitch due to a dropped field applies the filter to the wrong field from the glitch onwards, making the problem worse.

[Marvolo]

Thanks for all the forensic analysis and explanation!

but the definitive "proof" is in the DV version - it has the missing field

So... Not even the DV capture is perfect and without errors?? I would have thought that capturing DV was bullet-proof.

[Sharc]

Thanks for all the forensic analysis and explanation!

but the definitive "proof" is in the DV version - it has the missing field

So... Not even the DV capture is perfect and without errors?? I would have thought that capturing DV was bullet-proof.

pdr means that the DV version has that field which is missing in the HDMI capture. So the DV is correct.
(But yes, also a DV produced from an analog tape (source) can have glitches.)

[Marvolo]

Hi ya'll, I'm back.

So, I've set up Dual Boot on my computer and have now a native and fully supported Windows XP SP3 running (solely for the purpose of capturing) next to my common every-day Win10 system.
Luckily, my board is old enough to still support Windows XP fully.

Under XP, I managed to get my Blackmagic Intensity Pro 4K running, as well as both versions of Virtual Dub (1 & 2).
In VirtualDub 2, for the first time, I managed to have my Intensity Capture card produce the incoming video signal, enabling me to record. Something that wasn't possible when I used the same setup under Win10 back in June.

Some of you recommended using VirtualDub for capture instead of the Blackmagic Media Express software, as VirtualDub keeps track of potential missed or dropped frames.

I could record a test sequence of a few seconds and VirtualDub showed no missed or dropped frames.

Now, the only thing I'm not quite sure of is the settings. Which compression / codec should I use for capturing my Video8 tapes?

For the test sequence I used FFMPEG FFV1 lossless codec (1.3) in YUV 4:4:4, 8 bit.

Are these adequate settings for capturing lossless? It doesn't have to be uncompressed. I'm thankful for any compression resulting in smaller file sizes, yet it should remain lossless.

[poisondeathray]

I could record a test sequence of a few seconds and VirtualDub showed no missed or dropped frames.

A few seconds might not be long enough to determine if there are problems

For the test sequence I used FFMPEG FFV1 lossless codec (1.3) in YUV 4:4:4, 8 bit.

It should be 4:2:2, otherwise there is some upsampling somewhere going on and perhaps other transforms performed incorrectly .

FFV1 encoding is relatively slow with high overhead - this puts you at higher risk of dropping frames for capture. If you use it after the capture in a second stage - FFV1 can be an appropriate format to store for archival - It even has CRC check options . A negative is FFV1 has lower compatibility in commercial NLE's

[Marvolo]

I downloaded Huffyuv and Lagarith as well. Are they any better for capturing?
Apart from that, there's a ton of codecs that VirtualDub2 comes with, such as Blackmagic 10 bit 4:2:2 or 8 bit MJPEG Codec. Are they any good? Idealy, I would want those very raw captures to be archived. But I also want to process / edit them later in an NLE and then re-export them, probably into H.264 or something for viewing.

[johnmeyer]

I can't believe you are still trying to do this. Twelve pages of posts and responses, and the results you have posted have never shown enough of an improvement to make it worthwhile to continue this pursuit. More importantly, most of your attempts to get the "better" capture have resulted in problems that are far worse than your original DV.

My advice: spend your time editing the video and then enjoy it! Also, please learn from my experience: I have captured and saved hundreds and hundreds of hours of video (maybe thousands of hours) and the sad fact is that most of it will never be watched by anyone ... ever.

[Marvolo]

More importantly, most of your attempts to get the "better" capture have resulted in problems that are far worse than your original DV.

Is that so? I wasn't quite aware that it was "far worse" than the original DV files. Also, I was under the assumption that those "problems" that you saw in my earlier capturing attempts solely resulted from inadequate capturing which I hope I have now resolved with the new setup and VirtualDub.

That said, I was never going to delete the original DV files - so anything I'm doing now can't hurt the original files...

[poisondeathray]

I downloaded Huffyuv and Lagarith as well. Are they any better for capturing?

In terms of overhead huffyuv has the least overhead, but lower compression ratio, but lower risk of contributing to drops . There is a "magical" huffyuv version some people claim, I think it was discussed earlier a few pages back - but that would be anecdotal evidence. Huffyuv having lower overhead than lagarith or ffv1 are facts.

Apart from that, there's a ton of codecs that VirtualDub2 comes with, such as Blackmagic 10 bit 4:2:2 or 8 bit MJPEG Codec. Are they any good? Idealy, I would want those very raw captures to be archived. But I also want to process / edit them later in an NLE and then re-export them, probably into H.264 or something for viewing.

MJPEG is lossy

If you import your "Lossless YUV" videos into a commercial NLE, that is another can of worms - they incur loss - it was probably mentioned a few pages back too. BM 10bit422 or "v210" is "perfect" for NLE's in terms of compatibility (the other "lossless" codecs are often mishandled, clipped, treated as RGB) , but it is uncompressed and takes more storage. If your storage I/O is not adequate then that can also contribute to drops. The other format is uncompressed 8bit422 as UYVY . Those 2 uncompressed YUV formats are ideal for NLE's and treated correctly in most Windows commercial NLE's like Premiere, vegas, resolve . v210 is the common currency for pro NLE's even Resolve Studio - v210 like the "US Dollar". Open source NLE's like shotcut can handle things like lagarith, huffyuv YUV without clipping or mishandling - but the GUI's are not as nice and they have fewer feature - it depends on your goals/needs