I usually shoot at 4K 60fps H265 and the video file sizes are enormous. My hunch is that it should be possible to re-encode it to a smaller file size without a significant loss in quality, because slow encoding on my laptop might be more size-efficient than real-time encoding on the drone’s processor. I usually re-encode with
I am willing to accept some quality loss of course, I understand that this is not lossless. CRF 21 seems like a reasonable compromise.
I noticed that for a D Cine-Like video, this reduced the file size from 1 GB to 67 MB. It’s a 52-second video, 4K 60 fps. At least playing it back on my 1440p monitor, I don’t see an obvious difference. But the enormous decrease in file size makes me a bit suspicious, if I’m losing a lot without realizing it.
Well, I want the 4K 60fps. I’m keeping those parameters the same in the re-encoding. Given that my computer has more computational power than the drone itself, and that I don’t mind encoding at say 0.1x speed unlike the drone which is required to encode in real-time, it seems plausible that I might be able to get more efficient encoding that way.
Rich what you recommend settings for filming good quality but only need it for maybe send to friends upload to share or YouTube as I shoot in for 4k 60p if I’m doing slow motion but it’s normally 4k 24p but still big file like you mentioned but im always looking for best quality to feel good with the quality when sharing.
I’ve never bothered with 5.4 k 30p for unknown reason, probably because my laptop handles 4k videos smoothly so stuck to it.
Really interested as to whys and don’ts of size matters
The big decrease in file size is caused by a reduction in quality, even though much of that reduction is not easily visible to the eye—that’s the cleverness of the compression algorithm. There will be certain situations (e.g. in very subtle colour gradients, or certain adjacent high-contrast colours) where you might notice the compression of you examine the frames carefully, but overall the algorithm is designed to save data in areas where human perception doesn’t notice.
The drone will have used a high-quality compression setting to give you maximum flexibility in editing, so that you can increase or decrease exposure in editing, for example, without compression artefacts becoming noticeable. When you specify -crf 21 for the compression, you’re asking for a higher compression and therefore throwing away more data. If you open the resulting file in a video editor and try increasing or decreasing exposure, you’ll find compression artefacts popping out in the shadows or highlights respectively. And look at high contrast edges between an object and the sky: you’ll notice a difference between the original and the new version.
If you specify an even lower CRF you’ll begin to see more exaggerated quality loss. It’s similar to saving a JPEG in any app that lets you specify quality: you may not notice much difference between 80% and 100% but there’s a huge difference in file size. Saving at 20% will emphasise where it’s making savings. JPEG and MPEG are similar processes, I believe.
Looking at the info above I would guess you’re converting a 10-bit file in to an 8-bit file, which throws away a heap of data.
H.265 is currently the most efficient consumer video codec (best quality at the smallest size) so you can’t get the video files smaller without throwing more data away. (also h.265 ISN’T better quality than h.264 - it’s identical quality. The only difference is h.265 is more efficient and so takes up less space)
If you convert the kilobits into megabits it makes it a more universal format for video data rates and easier to compare; so your input data rate of152470 becomes 152.4Mb/s (that’s megabits, not Megabytes) and your output is 10183 or 10.1Mb/s, so already you have reduced the amount of data in your video file by nearly 14x so both colour and resolution will have suffered somewhere.
The most noticeable areas will be things like skies: instead of a smooth gradation you will see banding. You may even see macro-blocking; where apparently solid, uniform colours like a blue sky will look like lego bricks.
Details (especially complicated patterns like trees) look smeared and soft. Highlights like cloud detail can be blown out and become a solid white blob. Shadows can look muddy and lack detail.
In short MPEG codecs work by throwing away data that it thinks you won’t notice, like highlight and shadow data, and also throws away up to 75% of the colour data just to get the file smaller. Shrinking the files size even more will throw away even more data.
If you are only viewing those files on a phone or tablet you probably won’t even notice, but put them on a big screen - even a 27" iMac and you will immediately see all the artefacts.
By comparison a broadcast camera (which also uses MPEG-4 video compression) will generate files with a data rate of around 600Mb/s at 4K* 60P so you can see that 152Mb/s is already a compromise in quality. (which is why drones like the Mavic 3 cine also include a ProRes 422 intraframe codec).
This doesn’t mean the Mini 3 isn’t any good - I have one and I think it’s great! you just have to know it’s strengths and limitations.
Hope that helps?
4K on the Mini3 is actually UHD 3840x2160, not true DCI 4K. Blame the marketing guys at DJI.
It depends on what you want to do with it from there.
We like larger file sizes, higher bit depth and less compression in post production so you can push the material further creatively and the final file is still high quality (no noise, softness, artifacts etc).
Garbage In = Garbage Out.
If you are only going to watch them back without any further work it’s fine.
Basic rule is: always record at the highest possible quality and reduce only in post-processing for export. Always keep the original highest quality files because once you start compressing them, you can’t recover what’s not there anymore and any further processing just keep lowering the quality further than if you did it from the original.
As an example, take a raw photo, convert it to JPEG and even with the highest quality settings, you can see the pixellation in the JPEG file. Now resize the images and export again as JPEG (or for the kicks, convert to another format) and you start seeing the difference in quality growing larger and larger.
I’m keeping those parameters the same in the re-encoding. Given that my computer has more computational power than the drone itself, and that I don’t mind encoding at say 0.1x speed unlike the drone which is required to encode in real-time, it seems plausible that I might be able to get more efficient encoding that way.
