-
Is a capture and playback device a passthrough or a pitstop?
Hi guys,
Some of you already know that I’m researching the depths of what a capture and playback device does WHAT but that I’m looking for “precise” answers in a language a 2nd grader — me! — would understand.
Anyway — I’ve been going in circles for 2 and half weeks — no lie. I have so much in notes — in word, in notepad, on paper, in emails, IN MY HEAD — that I need to be UNCOMPRESSED!
I feel like all the answers are in my notes (so many notes). But the dots aren’t connecting, and part of the reason is that I’m getting opinions that seem to contradicting but in all probability are most like just not “sensitive” enough. The other part of the reason is that I’m a second grader!
The dots aren’t connecting because there actually are “holes” in the lines at the beginning and end the dots are. These holes are cause by the two “parts” mentioned above. I’m stuck MAINLY on one thing! And I need an a “sensitive” answer!! — not an industry answer! I need (and I say need respectfully) an answer sensitive the level of my mind’s current capacity not to shut off the moment an unfamiliar term injects it with fear and doubt.
So here’s where I’m stuck (and there’s gotta be a simple way to FULLY explain this):
1. why do we say that a cap and play device transfers uncompressed when a camera compresses the data when recording it, and since the camera’s decompression doesn’t fully restore. a full answer if possible. i will remember your name forever. full meaning something like this (though this probably wrong): well, a camera compresses it, then a cap and play connects to it via sdi, a button is pressed and a camera begins playback, and another button is pressed, and the cap and play sucks the wind out of the sdi and the sdi vacuums the footage out of the camera’s playback (yep, takes it right off the LCD), and then it takes the data, encodes it, and shoots it thru a thunderbolt pipe into a mac. oh ye and by the way — the playback was uncompressed. we call it uncompressed because the playback just orders the lost data to come out where it has fled to and get back in line to form a full original file in all its megabytes, and the guys that aren’t coming back — well we won’t even notice they’re gone. and so and so. (sorry for getting carried away. thanks if you’re still with me. help!)
2. when does the camera decompress — in playback or when you press the magic “decompress” button.
3. how do aja Io, BM UltraStudio 3d, and MXO2 transfer? does it serve as a passthrough or a pitstop? does it say: hang on data! cant go to the mac yet! we must do something to you first. we must: encode? decode? x? y? z?…
4. do all of the three machines mentioned above capture from playback only?
thanks. i’m in debt to you already if you’ve read this far.
val
-
4 Replies
-
hi. i did not get why you investigate all this ?
I see it as it really depends what camera and how it is compressed.
Cant say about thunderbolt but lets say you have DV material coming out of camera.
Camera makes it DV in hardware and sends it out by firweire thunderbolt etc.
So the compression stays the same all the way in dv and fw or thunderbolt or what ever is just
physical carrier so to say.It really depends on many details and it is not like all devices will give out uncompressed
and all can capture 444 rgb i.e. all data that your camera will give out.
So you have to look at the combination of devices (cameras and capture cards) and
compression methods they use.But lets go back and start from the beginning what is your master goal ?
—
Margus
-
Video I/O cards function as an interface between the file-based and serial-stream worlds. They can look into the encoded source media, and if its an understandable codec, in a recognized wrapper, whether its Quicktime ProRes, MXF DNxHD, or “Uncompressed 8/10-bit”, it will be able to map that data onto a memory raster that humans would be able to recognize if it was mapped onto a visual display.
In the file based world, the entire clip, for its duration, resides as data on some form of storage. There are ways of displaying every frame at once. In the serial world, each pixel comes out like water coming out of a hose, and we only see a recognizable image when they have been organized on a display (live), or going to tape and played back, another serial (single-stream, as opposed to parallel-stream) process that is time dependent. The frames follow each other like rolling stock in a train, and while they are in this temporal domain, they don’t actually conform to any codec, and are defined by resolution, frame-rate, and colorspace. You can playback MXF DNxHD from a Blackmagic SDI card, and capture it as Quicktime ProRes on a Kona card. For the brief instant that the data stream is in transit between the SDI output of one card and the input on the receiving card, it is “live” and for all intents “Uncompressed” and doesn’t exist as anything other than bits of data flying down the pipeline.
Some codecs are dependent on a stream of frames (long-GOP) since they need a group of spanned-data images to produce a coherent frame progression. Even in the file-based world, these codecs need to be processed in groups by editing programs in a serial manner, similar to adding water to a powder-based drink.
TMI?
jPo
You mean “Old Ben”? Ben Kenobi?
-
Guys, very sorry for the delayed response. Things just turned out this way. Margus, my master goal was to figure out what uncompressed means. I gotta say though, a lot of folks pitched in, and I now understand. Thanks for your efforts guys. Aside from understanding uncompressed, I picked up a lot of side-gems, so thanks for your efforts.
-
Hi again Joseph, I just read your response again and realized a few things in it that I didnt get the first time or two… “doesn’t exist as anything other than bits of data fluying down a stream”… this makes me wanna look further into “uncompressed 10-bit.” Anyway, just wanted to thank you for the time you took. It proved very important for me. Thanks.
Reply to this Discussion! Login or Sign Up