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.Originally Posted by Marvolo
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.
+ Reply to Thread
Results 331 to 360 of 368
-
-
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??
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.Last edited by Marvolo; 2nd Jul 2023 at 09:33.
-
-
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)
-
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.Last edited by Brad; 2nd Jul 2023 at 14:19. Reason: Replace Twitter link with VH link
My YouTube channel with little clips: vhs-decode, comparing TBC, etc. -
It's not just a bit-transfer from port to file like a FireWire "data copy" is.
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. -
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.
-
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? -
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? -
Want my help? Ask here! (not via PM!)
FAQs: Best Blank Discs • Best TBCs • Best VCRs for capture • Restore VHS -
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-logLast edited by Sharc; 3rd Jul 2023 at 08:39.
-
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] -
-
There is a drop between field 7 and 8 , without an inserted compensatory duplicate field this time
You "fix" it by recapturing
Look closely , while separating the Fields . There is a small jump between field 7 and 8
Code:FFVideoSource("Skiurlaub 1996_huffyuf.avi") AssumeTFF().SeparateFields()
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 -
-
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
-
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. -
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.
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.
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 ?" -
-
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
Code:ffvideoSource("Skiurlaub 1996_huffyuf.avi") assumetff().separatefields() histogram("levels")
-
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.
-
-
-
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. -
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.
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 -
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. -
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. -
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...Last edited by Marvolo; 30th Jan 2024 at 13:08.
-
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.
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
Similar Threads
-
"code":400,"error":true,"message" on http://getwvkeys.cc
By johnsonkiss in forum Video Streaming DownloadingReplies: 14Last Post: 25th Jul 2024, 21:45 -
{"code": 2048, "message": "Authentication failed"} when getting license
By warmachine in forum Video Streaming DownloadingReplies: 2Last Post: 26th May 2023, 16:34 -
Non linear audio delay in VirtualDub2 after "lossless encoding"
By Hunterh in forum Newbie / General discussionsReplies: 6Last Post: 16th Jan 2022, 07:21 -
"Honestech VHStoDVD Deluxe 8" Shaky video transfer-8mm camcorder cassettes
By Edna Oomen in forum Newbie / General discussionsReplies: 1Last Post: 27th Feb 2021, 14:31 -
"Lossless" NVENC bitrate vs x265
By savvyguy in forum Newbie / General discussionsReplies: 0Last Post: 18th Aug 2018, 22:28