Sat Aug 08, 2015 7:24 am
@David Williams, no lightweight codecs dont make cameras toys, but lets have a look at what purpose they serve. Inside the camera is a hardware based encoder for whatever the camera records. This is an optimised system for making a single format of the manufacturers choice. Its purpose is to encode the video to the card in a way that the data, to the best of the ability of the encoder, can be read by something else. The only device that is designed to decode that format specifically is the camera itself. these formats are designed for single direction playback and not for scrubbing, varispeed or random access. I don't think anyone can edit by only playing files at normal speed from the absolute beginning (and that is what these files are designed to do). That is why formats like pro-ress exist they are made for varispeed, random access and bi-directional playback with an optimised decoding process.
Camera formats like MTS etc are intermediate, or best used for preserving and moving representation data. You do not have this dedicated chip inside your computer to decode this media. You have to instead use a complex and resource hungry system to do so.
It will really slow your system down, if you want to dedicate so many of your resources for editing and grading to do something that was designed to be done with low level optimised hardware- you are free to use your computer resources as you wish.
Your scenario is instead of transcoding once, you want to use your limited system resources to do a real time transcode every single time you play every single frame. Instead it seems much more logical to transcode once and then let the system run more efficiently, letting you be more creative and more responsive and faster at moving from idea to edit or grade while you work.
FCPX for example will create optimised media (transcode) underneath with its default settings- you just don't have to wait for it to be finished. Having said that it will also start offering lower and lower resolution preview playback as your system resources are used. For many of us we want to see a little more than a 1/8th playback quality when working.
There is a lot of logic for transcoding and very little against it. If transcoding is taking a long long time, then maybe your computer is not the fastest. In this case, when it comes to real time you should do as much as possible to preserve those resources, like transcode your files to a format optimised for random access and lighter decoding.
As a side note try taking some samples of transcoded and non transcoded video and see the performance difference you get, it is quite big, especially when you have more than one layer. This is not a limitation of resolve, other NLE's have some ways around this but this process eats resources and is not needed.
Quality loss is not really relevant here. Many of these compressed codecs from cameras require multi-pass decoding to make the best of the image, by definition this cannot happen in real time. The process of decoding in real time, compared to transcoding is no different except that with multi-pass decoding you will get better results.
Of course you can also choose pro ress proxy, it is much smaller and if you work with a good data management system (well labelled disk images of every record), you can reimport high res media from an offline timeline at the highest quality (remember online?) It is a great workflow, speeds things up and saves space. It also gives you easier to manage projects and backups.
If you are worried about quality I believe the only thing you have to do is make sure there is more information in your destination format. Many of these small b-roll cameras are recording 420 so make sure you use 422, or go for 444 if you are really worried. Generally for small cameras pro-ress 422 and higher will be able to hold a lot more information than your cameras encoding type, and getting that information from a multi-pass dedicated decode will give better results. In theory the only thing that will play back the recorded footage as it should be is the camera itself so if quality is your guide then play out the footage from the cameras HDMI port and capture it in real time- this should give the truest results from your image as the encode and decode chip are the same.
In the end there are other NLE's that let you make bad choices, FCPX is a very good example, you can make any bad choice with your workflow and will probably function ok, and if you leave the default settings and let it "optimise" your media it will eventually sort itself out. Generally though FCPx also treats you like an idiot and will not even let you see your files and many just dont like it.
So the question may not be about what is a toy camera and what is not, but more, should Resolve start to let encourage and facilitate people to make bad choices in workflow? I think no, and the biggest reason is that if you make better choices your whole system will run better and your experience with resolve will be better and your work will be better.
In the end transcoding is the "correct" way to do things, your computer may be able to let you skip it, but is that really a good thing to do? Do you really save time and disk space- the caching you will need to use to get back your system resources will eat the disk space and all the extra seconds stopping and starting playback and the reduced responsiveness of your system may well add up to something close to time of transcoding.
http://www.fredrodrigues.net/
