I need to check my settings as well! I assumed the default was 422.
John, I think your results are probably correct. I've been scratching my head over this; my first result seemed improbable except in context with 444.
I am still looking for "YUV Magic," if such a thing truly exists. As far as file size, John, was your Sony YUV codec 8- or 10-bit?
If Magic 444 is truly 4x smaller than Sony 422, this may be "case closed" on size, quality, and speed. So much for monolithic thought processes in production, doh?
Again, I'm really glad to have other sets of eyes on this. I'll try to find a way to measure true PSNR using the chroma interference bars.
I added UTVideo 444 to my results page. I use a flavor of UTVideo for my OBS screen recordings on an older, slower machine that has a lot faster I/O than CPU.
I did a test render of MagicYUV RGB vs MagicYUV 444.
MagicYUV RGB. Rendered in 21s. File size 3.82GB. CPU on playback: 35% steady. 100% lossless.
MagicYUV 444. Rendered in 24s. File size 3.34GB. CPU on playback: 40% with some spikes to 50-60%. Visually lossless on my display but significantly lossy on the videoscopes.
Will be sticking with the RGB flavour for my intermediates. For me, I don't think the modest saving in file size is worth the other factors.
It snowed today and the Broncos had a bye week so here are some numbers.
SSIM is a Structural Similarity tool that picks up compression artifacts, among other things. PSNR is Peak S/N Ratio, aka shadow noise. 30-50 psnr is good for compressed camera video, but not so good for animation and generated motion media source.
The AVC internet numbers, which are the only 420 interframe compression example, may be artificially high because the effects of temporal processing, such as motion estimation, cannot be factored in.
On the clip I tried (which was of a load of puffins, and not color bars) I can't see any difference with my eyes but my video scopes move significantly. The histogram gets kind of jagged.
Updated to include new codecs, correct typos and added "ratings, " 1 being the best, 5 being yesteryear's best.
Magic and UT RGB are pretty cool, iindeed. Yesterday I "thought" I could see the effects of 40 dB PSNR in the 422 render, but now I'm not so sure. (I was a grain-peeper, well before there were pixels.)
I waffle a lot here on subjectively held beliefs. This time around, the eyes aren't helping.
Lagarith, Cineform, DNxHD, will not be tested for various annoying reasons.
I am having fun learning the new version of the MSU SSIM Tool.
Here's Uncompressed RGB vs. 422; this is the one that puts it all in a better perspective for me.
For the majority of my full-motion work, RGB at 13% of Uncompressed size is the sweet spot afaiac.
For larger projects and slideshows, 422 at 1% of Uncompressed size is ideal, lacking conclusive evidence of visual differences, again afaict. 444 is just a red herring because it is no smaller than RGB, and takes longer to compress.
I downloaded Magic YUV and it just keeps giving me the error message: "The selected codec does not support the current render settings". EDIT: I changed it to Magic YUV RGB and it worked - sorry! I say it worked, but it estimated a render size of 1GB for a 40 secs timeline, and gave me a rendered .avi file of 3.45GB! The files I have (Galaxy S7 - Video: 00:00:08.289, 59.233 fps progressive, 1920x1080x32, AVC Audio: 00:00:08.255, 48,000 Hz, Stereo, AAC) are only short clips amounting to about 260MB in total so I'm guessing I am missing something obvious. Originally I just wanted to render this project (I just edited out the footage I don't want from some clips) as lossless as possible for further editing and came across this thread. After much searching, I've found nothing that states that this is even possible. Am I missing something glaringly obvious here also? Thanks for any help/input/feedback
I've just re-read this thread and maybe there is something I didn't properly understand. Although Nick didn't mention how long his edit was, as it rendered in 21s and the resulting file size was 3.82GB, I'm guessing this is a good result? I'm just shocked that I'm working with files totalling 260MB which equate to a 3.45GB file when rendered together as a .avi. I'm just reading an article about rendering intermediate files, so maybe my question will be answered in that!
Without your own test data and file properties, we can't draw comparisons. Here's a basic math formula for you to work with:
Time (Sec) x Bitrate (Mbps) x .125 = Size (MB)
This thread did not intend to compare render times, which introduces outside variables (equipment and source).
Welcome to the discussion, and keep thinking!
Was this comment directed at me? If so, I'm confused, as my only reference to render times was the one Nick Hope posted. I just don't really understand how a rendered file can be nearly 14 times the size of the original footage! Again, it is quite possible that I am just not properly informed or still have much to learn!