Capturing Uncompressed Video8 and VHS-C then Compressing

[mayhampixi]

Ok,
So my setup is:

BM Media Express
Adobe Premiere CS5.5
BM Intensity Shuttle
TBC 8710
Video 8 Camcorder (one that was used originally)
Supercomputer

Im connecting the Video Camera via chunky Composite cables (camera only does Composite out) into the TBC then into the BM shuttle.

I have about 30 Video 8 home movies and about 30 VHS-C home movies. so about 60 tapes

What i wanted to do is basically capture the video at the best setting either YUV 4:2:2 10bit or 8bit im thinking.

I was thinking of keeping one copy for myself on the best resolution uncompressed on a couple of HDD's and then storing it safely.I am trying to decide whether to go 8bit or 10bit (not sure yet) as an hour is over 100GB, not that space is such a problem but wondering if i need 10bit, i have read there is a quite a difference between them, maybe 20% is it that much? I'd rather not have to do this again so if its just HDD space then maybe 10bit.

what i wanted to do after i have captured them all uncompressed, is to then compress each file to about 30GB for an hour tape, or there abouts without loosing too much quality so i could give a copy to Mum and Bro on a 2TB HDD Media player. That way they will get all 60 tapes on one 2TB media player.

Whats my best options? I read about HuffYUV, is that a good Codec or can Adobe Cs5.5 do it
Or should i just capture it again in a lower setting?

Cheers
Thanx for all the help!

[jagabo]

With consumer tape formats 8 bits is sufficient. The lower 2 or 3 bits is all noise anyway. You may find uncompressed YUV 4:2:2 (usually YUY2) is too much disk bandwidth to capture safely. Using a lossless codec like HuffYUV gets the disk bandwidth down enough to prevent dropped frames without over-taxing the CPU. But does the BMIS allow you to use system installed codecs?

[mayhampixi]

Im a bit new too all this..
So is what ur saying, the codec has to be used at the time of capture?


I captured one last night at 8bit, 90 minute tape was just over 100GB
My computer handled it well and no dropped frames. I only built it recently for this purpose.

Im using Adobe Premiers CS5.5 for capture, but can use Black Magic Media express.
Im not sure if either will be able to use the Codec,

Maybe i think i need to do a bit more reading on codecs.

I was more under the assumption i capture it uncompressed and then compressed it later..
More google time!

thanx for the reply!

[jagabo]

Im a bit new too all this..
So is what ur saying, the codec has to be used at the time of capture?

No, you don't have to compress while capturing but it's safer. With fast codecs you're less likely to drop frames. And it saves on disk space, of course. With lossless codecs you don't lose any quality.

I captured one last night at 8bit, 90 minute tape was just over 100GB

Yes, That sounds like uncompressed YUY2 or some other YUV 4:2:2 variant.

My computer handled it well and no dropped frames.

It sounds like you're ok. If you trust what the software is telling you.

I was more under the assumption i capture it uncompressed and then compressed it later..

With fast lossless codecs there's no reason not to compress while you capture. Those types of codecs are designed for that type of use. It's when using slow codecs (h.264, MPEG 2, etc.) that you want to compress later. Those codecs are too slow to compress while capturing.

[mayhampixi]

No, you don't have to compress while capturing but it's safer. With fast codecs you're less likely to drop frames. And it saves on disk space, of course. With lossless codecs you don't lose any quality.

Ahhh now it seems to be coming together for me!

Ok so i guess the next quesiton is which codec to choose..
I have read a little on MSU and FFV1 but Lagarith and Huffyuv seem to get the best write ups.
I would rather not drop frames, actually definatly not drop them, thats why i forked out the $$ for the TBC which has worked perfect last night for its first time. So i guess i will try maybe to capture in CS5.5 with the Lagarith codec??

It sounds like you're ok. If you trust what the software is telling you.

How trusting should i be of Adobe Cs5.5? So far i have trusted completely..

Awesome website, heaps to learn but great help!

[jagabo]

MSU is too slow for video capture. I don't know about FFV1. Lagarith is slower than HuffYUV but compresses a little better. An i7 2600k is probably ok with Lagarith. I don't know much about Adobe CS. The big issue is whether it can use system installed VFW codecs.

[mayhampixi]

Does not look like i can use Largarith to capture.. What program does?
I can however use Largarith in CS5.5 when i export.

Been looking for settings for Largarith

Some people say export RGB and its the best but a memory hog, also that you can then specify the proper matrix in avs script later when editing.
Others say YUY2 and then there is YV12 and RGBA which i still dont know about.

I really dont know the difference and have made the effort to find out but cant seem to get an answer at the moment i have 10 windows open that sort of explain it but not.

So i guess by reading what i have RGB or YUY2.... what do u recommend?

then there is the option to prevent upsampling when decoding ( which will force the codec to decode the video in the same colourspace it is stored as internally, it might improve performance but might not be compatable with some programs????

and null frames,,,,, by the description i dont need this checked...


THanx!!

[jagabo]

Been looking for settings for Largarith

Some people say export RGB and its the best but a memory hog, also that you can then specify the proper matrix in avs script later when editing.
Others say YUY2 and then there is YV12 and RGBA which i still dont know about.

Capture in YUY2 (or similar YUV 4:2:2) and compress/decompress as YUY2. YUY2 is closest to what's in the analog signal. All capture cards capture as YUY2. If they offer an RGB capture mode what they are doing is converting that YUY2 to RGB on the fly. Converting from YUY2 to anything else will lose information.

Null frames: if a frame is exactly the same as the previous frame the codec can just say "repeat the last frame". That's not ever going to happen with analog tape captures.

Prevent upsamping: if you capture as YUY2, compress as YUY2, and decompress as YUY2 there will be no up/down sampling.

reading material: http://fourcc.org/yuv.php

VirtualDub is good for capturing but I don't know if it will work with your device.

[mayhampixi]

Ahh Gem!
Now i understand, i wonder why i spent hours trying to find that info, and couldnt.
Solved I will Try tonight. Ill start searching for VirtualDub and see if it is good for capturing with BM device.

Thanx Again!

Slowly getting the hang of things now. Fun!

[2Bdecided]

what i wanted to do after i have captured them all uncompressed, is to then compress each file to about 30GB for an hour tape, or there abouts without loosing too much quality so i could give a copy to Mum and Bro on a 2TB HDD Media player. That way they will get all 60 tapes on one 2TB media player.

And what are they going to play it on?

Because not all hardware plays back SD video at 67Mbps!


Bits may be cheap, but what you're proposing is probably overkill.

If you care this much, check first that the "Video 8 Camcorder (one that was used originally)" is doing as good a job as a decent "modern" VCR with built-in TBC.
Consider also the restoration you might apply to the images.

Remember too that the original VHS recording is setting the quality limit. You can try to get the best out of it, but I suspect 67Mbps is a little beyond this

Cheers,
David.

[jagabo]

Yeah, it doesn't make sense to distribute the videos in a losslessly compressed format unless you're in a competition to see who can do the best filtering. I don't know of any standalone media players that will play any of the lossless codecs.

You're best bet is to keep the lossless video for yourself as a permanent archive and encode with MPEG 2 or h.264 for distribution.

And most important is to use a line TBC before capturing to get rid of all the horizontal line jitter that's common to all analog tape formats. That can't be fixed after capturing.