8
« on: November 18, 2015, 06:33:01 pm »
This is a technical document which I've been intending to write for a while, and I figured now would be as good a time as any to actually do it. Technically this is related to the video requests section, but it's more of a general knowledge document, understanding the technical side of things.
If you actually want to UNDERSTAND how it works, and how to get the absolute best out of your equipment, then you might want to read on this.
If you want a place to start, you can read through the document and see where you can end up, for what you're willing to invest in time and resources.
----
Before we go any further...
"I already have X setup, and it's good enough! Why the hell do I need to understand any of this technical crap?"
If you are satisfied with good enough, then yes, what you have will suffice. You may be surprised by the price differentials and the quality (or quality of life) improvements you can get for relatively cheap though.
That and you can deal with the fact people who want to get better and produce higher quality work will want to work their way up, and eventually make your work look bad. Unless you already know this stuff, and more, in which case 'You wouldn't be asking that question'.
... Any other questions? No? Good, let us begin.
Starting at the bottom: Where do I start, and how?
Now, if we're dealing with the absolute basics, all you REALLY need is a device that will capture video to your PC. There's quite a few of those, but you know, they all vary in quality and a whole bunch of other things.
Now, to understand what a device DOES to achieve its capture, the easiest way to understand the device is actually by its requirements to operate. Unsurprisingly, the better the device, the more the device requires to work.
So how does this thing work anyway?
This is your first port of call. Usually how you install the device will tell you leaps and bounds about how the device operates, or more accurately, what you should expect out of the device in quality terms.
I do need to take a detour before we start though.
-----
Quick lesson before we move on - understanding how video is recorded digitally.
Now, when you see video, there's a resolution attached to it, as well as a framerate. I'm pretty sure most people would be aware that 720p video looks sharper than NTSC or PAL, and 1080p video looks sharper and cleaner than 720p. 60 frames per second feels smoother than 30 frames per second, or 15, and so on.
Thing is, to perfectly capture a video, the device needs to write to disk all the data in question.
Funny thing is, the math for this is KNOWN, because what you need to do is store the colour information for each and every one of those pixels. For example a 4:2:2 RGB colourspace, you need 4 bytes for Red, 2 for green and 2 for Blue. It's a fairly common one, although there's weaker standards such as 4:2:0 YUV which uses less data per pixel, and if you ever watched an anime that looks washed out, then you get the Bluray and it looks more vibrant, there's a reason why.
There's 1280 pixels across and 720 down for a 720p source, and you'll also need some overhead to put the data in a matrix and link each still frame one after another.
The math gets complicated, but it amounts to 'If you want pixel perfect capture at 720p60, the device that's writing the data needs to be able to dump about 240-260 MB (That's MegaBYTES, not Megabits) per second, every second. At 1080p60, you'll need about 550-600MB/s'
What happens if you can't record the data at that speed? Simple, you lose data because you missed it. In short? You lose frames.
Now, for pretty practical reasons (Namely, that's a LOT of data per second of footage!) we don't actually store our video this way. Or basically, there's a reason why I don't normally send the 'raw footage' of im@s video recordings - downloading 16GB for 2 minutes and 15 seconds of footage is insane, if only because entire GAMES aren't that big in a lot of cases.
So we run an encoding process, which means we compress the video. In a lot of cases, because we're interested in making it visually close, we compress the video with what's known as a lossy codec. This means when we run our compression, we drop a lot of detail that most people wouldn't honestly really notice (eg certain gradienting) which in turn brings the filesize down.
As an example, most anime subs at 720p24/30 are what, 300-500MB for 25 minutes? That's a lot less insane than the lossless (If I was to record an anime using the capture equipment, you'd be looking at oh just say 80GB for that same episode?) and is more practical for transport.
Bear in mind that this sort of compression is done AFTER you have a final video. You don't do it on the fly if trying to get the smallest file size and best quality is your goal.
Now, if you're going to ask 'So why can't I compress lossless on the fly and try to cheat the requirements a little?' well...
The kindest way to put it is this way - the processing power required to do so is immense, and the moment the CPU stalls because the codec doesn't know how to handle a certain image in the timeframe it has, you lose that frame. And probably six or eight either side.
If you've ever watched a TV broadcast, and the image goes weird with pixelated blocks, bad colour or a whole raft of weirdness, that's one reason why it could have happened. Generally the codec that governs this equipment (while very good) cannot handle certain colour or light patterns. In the TV world (and real life) there's a lot of things that don't happen nearly often enough to cause the codec to choke, so you can get surprisingly good on the fly encoding if you're prepared to fork over the money.
Funnily enough, streaming uses a variant of that, and gaming is also the one thing that can throw very unnatural patterns. In fact, I usually use a particular game (Atelier Totori) to test compression codecs with their robustness. Most of them fail miserably.
-----
So what did this aside teach us? The fact that if you CAN'T write that fast, you MUST be compressing on the fly, and consequently you must be suffering various degrees of information loss.
Now, we start to cover the first step in determining how good a device is - How you get it to work with your computer.
USB 2.0 vs USB 3.0 vs Thunderbolt vs PCI-e
If the above statement made absolutely no sense to you, the fastest way to cover it is this:
Does your device plug into any USB port?
Does your device require you to plug it into a very SPECIFIC type (namely a blue marked) of USB port?
Does your device require you to use a Mac specific (well, near now) port?
Do you have to open your computer and plug it into a slot that could also fit your graphics card, or maybe your sound card?
How you answer that question will determine what the device HAS to do to record.
If you can plug it into any USB port, it's a USB 2.0 device. This means (Because I can read tech specs) that the device is limited to an absolute throughput of 300Mbps, because that's what the port ITSELF supports. Not 300MBps, you're off by a factor of 8.
Adding in technical overheads and encoding and a whole bunch of other stuff, and it REALLY amounts to 'USB 2.0 can transfer on the best of days about 30-40MB/s'
The good news is that the device can work on most computers because you don't need a write speed that fast.
The bad news? Well, you're compressing 82.5% of all the data in 720p, and somewhere close to 96% of all the data at 1080p. A lot of information's going to go missing.
If you're just planning to just show your friends, some quick and dirty videos or streaming, it's probably good enough. If you intend to do anything to the video (like say a mashup, or some other video work like say a mini documentary or something) you'll probably be griping how the bits look worse compared to what you're working on.
If you're holding a USB 3.0 device AND the device says you need 200+MB/s write, then you might be in luck, assuming you have an SSD in the PC that's doing the operation in question, and it writes fast enough.
Maybe. If the stars align.
There's been... shall we say 'issues' with the implementation of USB 3.0
I could go on for a while about the problems, but it amounts to this - the maximum throughput of a USB 3.0 port is SUPPOSED to be 6Gbps. If you're wondering, that's about 500MB/s.
To do this, what mainboard manufacturers do is use the PCI-e lanes to provide the throughput to support the port. All well and good so far right?
Well, here's the kicker. A LOT of the implementations usually limit you to 1 PCI-e lane. Maybe 2. Why? Because PCI-e lanes are a premium, and configuring the board to properly send data everywhere is expensive, and a lot of manufacturers don't actually expect people do tax the USB 3.0 port to its actual theoritical maximum.
Each PCI-e lane is 600Mbps. If you're working with PCI-e v2 or 3, it's 1200Mbps (Before you ask, v3 doesn't triple the speed, it makes each lane more reliable). To do it properly you need at LEAST 4 (8 on older implementations)
Considering the hard cap of PCI-e lanes on a board is between 24 and 32 lanes total, and you need to allocate them for stuff like graphics cards and the like, you can see why cheat, and hope no one REALLY cares.
To be fair, if you're transferring onto a USB 3.0 thumb drive, you probably wouldn't REALLY notice.
Your capture card will though, and this is why USB 3.0 is basically shooting in the dark as a reliable medium - You have to be SURE your board (be it laptop or desktop) does it right, because so many manufacturers do it wrong. Generally those who need one generally know exactly what they're doing, and buy from places who ARE willing to accept returns due to this guessing game.
Yes, I've played the guessing game before, and for the record, it sucks (And to complicate matters, we even had a malfunctioning unit to throw into the mix).
Now, if you're told 'You need a thunderbolt port/New model Macbook/pro to use this device with a SSD or other device that can write at 200+MB/s' then lucky you, you don't have the USB 3.0 conundrum. I can also hazard a guess which of the two devices on the market you have too. (They're not that common.)
Why? It's pretty simple - All implementations of Thunderbolt are geared to work at a guaranteed minimum of 10Gbps. (The actual limit is 12Gbps, which is for the record about 1GB (as in Gigabytes) per second) This was in part due to the fact Thunderbolt was also designed to feed apple displays at 1080p, 2k and 4k WITHOUT the use of HDMI. Yep, it can carry HD signals if you know how to do it, and if you remember the math, you'd know how much data needs to go through this port to do so lossless.
Apple contracted the work to Intel, and forced the spec to be very specific - By the time this spec became available to non-macs, the design was very rigid, so there's no need to pray.
Of course, if you need the write speed, well you still need the write speed to record. Otherwise... compression city folks.
If you have to have a desktop, and you have to open up the device and install a card, you have a PCI-e card.
Now, if the card says it absolutely needs the ability to write fast enough because it doesn't compress, that's what it says. Compression or write speed is YOUR problem, and you can choose to go lossy, or write raw, or try your hand at lossless on the fly. The device will often not do anything other than show the signal.
If it insists it DOESN'T need a particular write speed, then the card itself has a compression chip (or set of chips) forcing lossy compression. Since it's dedicated hardware it can be surprisingly good, but well, the device still needs to do so on the fly.
Now in terms of pricing, devices that compress tend to be relatively cheap (barring a couple of very specialised exceptions) since well, you're wanting a signal, not a GOOD one. You shouldn't be paying more than about $200 US for a device that forces compression, unless you absolutely know you need it (Broadcasting with a laptop, where you know the laptop cannot handle the compression.) Said device is 450 US, but is used by TV stations around the world for snap setups.
Why? Because you can get devices above 200 USD that do BOTH compressed and uncompressed. Unless you're working with a very old computer (as in say Core 2 Duo or older) you probably can do the compressed option just fine.
If you want to capture lossless, you want to read the box, and read the requirements. If in doubt ask, and in the process become friends with your supplier, because he'll realise you're not a gaming moron who he can milk money out of.
If you're willing to play the guessing game with USB 3.0, you can get decent uncompressed USB3.0 devices for what 200-250 USD?
If you have a spare PCI-e slot in your computer that is 4x or bigger (Read your mainboard specs for that one) you can get capture cards for 200ish USD that can do lossless 1080p60 if you want it to.
Now, why do I recommend this as an option?
Because of the fact it's now relatively cheap to get the write speed.
For an idea, a 250 or 256GB SSD can be had at about 150 US, as long as you have a computer that supports SATAIII (at 6Gbps per drive). This will be enough to support 720p60 lossless recording for about 35 minutes. They are extremely fast, and basically as long as you don't buy some dodgy SSD (once again, be friends with your retailer) you'll do just fine.
You can get bigger ones for more money of course, and if you have the space and the ports to connect the drives you can RAID 0 them up, and basically use them as one super drive.
Congratulations, you now know how easy it is to retrofit virtually any system made in the last 3-4 years into a recording station, without spending a mint on a new PC.
Now this should end Part 1.
What, there's more, and I'll be covering a topic that will drive everyone nuts, because, well it does. How do the inputs work? What the hell is HDCP, and why the hell am I seeing slight rings on my recordings anyway?
Don't go shopping just yet, we'll be right back after I get some sleep. No, really don't, because you might want to understand the next bit BEFORE you commit to this.
Show Posts