Creative COW SIGN IN :: SPONSORS :: ADVERTISING :: ABOUT US :: CONTACT US :: FAQ
Creative COW's LinkedIn GroupCreative COW's Facebook PageCreative COW on TwitterCreative COW's Google+ PageCreative COW on YouTube
FORUMS:listlist (w/ descriptions)archivetagssearchhall of famerecent posts

Re: Is a capture and playback device a passthrough or a pitstop?

COW Forums : Media Formats | Media Capacities

VIEW ALL   •   ADD A NEW POST   •   PRINT
Share on Facebook
Respond to this post   •   Return to posts index   •   Read entire thread


Andrew RendellRe: Is a capture and playback device a passthrough or a pitstop?
by on Dec 27, 2011 at 11:12:36 am

Let me try to unpack that:

"why do we say that a cap and play device transfers uncompressed"
The cable connecting the devices uses a format which carries the data at an uncompressed rate, so if the data is uncompressed, every digit will be transferred without modification.

"when a camera compresses the data when recording it, and since the camera's decompression doesn't fully restore"
Compression does not simply throw away data. What it does is replace big blocks of data with smaller ones which approximate the original data. When you decompress you get a complete data stream (the same as the uncompressed version) but some of the information in that data is an estimate of what it would have been if the data hadn't been compressed.

So:

"a camera compresses it"
Yes

"then a cap and play connects to it via sdi"
Yes

"a button is pressed and a camera begins playback"
Yes

"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"
You mean data goes down the sdi wire, having been uncompressed by the camera, and is received/recorded by the capture device, in which case; Yes

"(yep, takes it right off the LCD)"
I haven't got a clue what you mean by that.

"and then it takes the data, encodes it, and shoots it thru a thunderbolt pipe into a mac"
Yes, well sort of. Some capture devices do the encoding (i.e., compressing) to whatever codec you choose in the box and send it to the computer, others use some of the computers processing power to do part of the job.

"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"
Not quite. The lost data is lost, but the data that's kept has information in it that allows the player (in this case the camera) to make a good guess at what the lost data would have been and it uses those guesses to fill in the blank spaces. So some of the data in the the uncompressed data stream has been compressed and then de-compressed.

"and the guys that aren't coming back -- well we won't even notice they're gone. and so and so."
Well, that depends upon the compression; how much data is removed and how the remaining data is encoded will have an effect on how well the system can guess the values of the missing data - good guesses mean you won't notice what's gone, poor guesses (based on too little information) will be noticeable.

"2. when does the camera decompress -- in playback or when you press the magic "decompress" button"
Normally whenever you play back the camera decompresses for it's outputs, you don't have to press an extra button to decompress.

"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?..."
There is a slight delay as the device does it's processing. You will find that if you take the sound into the computer by a different path you may have to assign a delay into the software to maintain lip sync, or if you place a monitor from the computer next to one showing the camera's output direct you will be able to tell that the picture on the computer display is slightly delayed relative to the direct feed.

"4. do all of the three machines mentioned above capture from playback only?"
The short answer is no, they can also capture from a "live" camera feed, it doesn't have to be recorded, and if it hasn't been recorded it hasn't been compressed so the uncompressed feed can be uncompressed data.
[The long answer involves a bunch of technical stuff and you'll need to get the full spec of each device from the manufacturer to work out what's feasable and how much effort it would take to get a working system.]

Hope that helps.



BTW, The SDI cable connecting camera/deck to IO box is generally the right way to capture from videotape (or a live recording from the camera) but it's not always the most efficient. DV and HDV can be transferred by Firewire and that will save a decoding/encoding step as the firewire feed isn't de-compressed (and you want to keep the number of processing steps to a minimum as each processing stage has the potential to degrade your quality). If you have a compressed recording on a memory card it'll be more efficient to copy that file into the computer using a card reader.


Posts IndexRead Thread
Reply   Like  
Share on Facebook


Current Message Thread:




LOGIN TO REPLY



FORUMSTUTORIALSFEATURESVIDEOSPODCASTSEVENTSSERVICESNEWSLETTERNEWSBLOGS

Creative COW LinkedIn Group Creative COW Facebook Page Creative COW on Twitter
© 2014 CreativeCOW.net All rights are reserved. - Privacy Policy

[Top]