Comments

john_dennis wrote on 11/9/2018, 9:09 PM

I did test renders and placed the output back on the timeline to compare using Composite Mode Difference. Here are screenshots of each comparison.

Uncompressed

Sony YUV

Magic YUV 4:2:2

Magic YUV 4:4:4

UTVideo 444 YUV BT709

Magic YUV RGB

I have questions about my methodology.

I thought I'd throw in the render settings that I most commonly use as a delivery format as a sanity check.

AVC/AAC

File Size Comparison

Nick Hope wrote on 11/9/2018, 9:31 PM

Which flavour of MagicYUV are you guys using? MagicYUV RGB is 100% lossless for me, every time.

john_dennis wrote on 11/9/2018, 9:54 PM

I'll add Magic YUV 4:4:4

Musicvid wrote on 11/10/2018, 7:15 AM

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.

Anyone got ProRes 422 to test?

john_dennis wrote on 11/10/2018, 9:12 AM

I used the 8 bit version of Sony YUV.

Musicvid wrote on 11/10/2018, 9:54 AM

That's a huge size, and I presume rendering time savings.

I'm going to dust off UT codec and compare 444 compression.

john_dennis wrote on 11/10/2018, 11:00 AM

 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.

Musicvid wrote on 11/10/2018, 3:45 PM

And you report 9% smaller than UT. And Handbrake reportedly accepts it now.

 

Nick Hope wrote on 11/10/2018, 8:57 PM

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.

john_dennis wrote on 11/11/2018, 12:43 AM

@Hope

"Will be sticking with the RGB flavour for my intermediates."

I rendered Magic YUV RGB and added it to my results. I found it indistinguishable from the original.

I tend to agree.

Musicvid wrote on 11/11/2018, 9:06 AM

Are you seeing a difference between 444 and RGB ?

I think I have a way of running SSIM analysis on these that would indicate if there are perceptual differences.

john_dennis wrote on 11/11/2018, 10:16 AM

I'm able to measure a difference between Magic YUV 444 and Magic YUV RGB.

What I can see is a completely different matter. 

Musicvid wrote on 11/11/2018, 6:12 PM

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.

 

SSIM 1.0 = 100%

PSNR 100 dB = 100%

 

Nick Hope wrote on 11/11/2018, 11:53 PM

Are you seeing a difference between 444 and RGB ?

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.

Musicvid wrote on 11/12/2018, 6:03 AM

Well some old favorites seem kind of bland against "newer" RGB codecs. UT was just coming into favor the last time I really looked at this.

 

wwjd wrote on 11/12/2018, 7:22 AM

can some smart person do an idiot's guide rating from 1 to 5 stars on each result? (I know size and other factors will affect people's needs and uses)

Musicvid wrote on 11/12/2018, 3:04 PM

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.

http://www.compression.ru/video/quality_measure/vqmt_download.html

 

Musicvid wrote on 11/14/2018, 3:08 PM

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.

.

 

Musicvid wrote on 11/14/2018, 6:24 PM

@Hope

"Will be sticking with the RGB flavour for my intermediates."

I rendered Magic YUV RGB and added it to my results. I found it indistinguishable from the original.

I tend to agree.

+1

chris-h wrote on 1/19/2019, 2:46 PM

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

Last changed by chris-h on 1/19/2019, 2:58 PM, changed a total of 2 times.

Laptop (Windows 10 64Bit)
Processor (CPU) Intel® Core™i7 Quad Core Mobile Processor i7-4810MQ (2.80GHz) 6MB 
Memory (RAM) 32GB KINGSTON HYPER-X IMPACT 1600MHz SODIMM DDR3 (4 x 8GB) 
Graphics Card NVIDIA® GeForce® GTX 880M - 8.0GB DDR5 Video RAM - DirectX® 11 
Memory - Hard Disk 250GB Samsung 840 EVO SSD, SATA 6Gb/s (upto 540MB/sR | 520MB/sW) 
2nd Hard Disk 500GB Samsung 840 EVO SSD, SATA 6Gb/s (upto 540MB/sR | 520MB/sW) 

Cameras
Canon 5D Mk3
GoPro Hero 4 Black
GoPro Hero 7 Black
Samsung Gear 360
Samsung Galaxy S7

Vegas Pro 16

chris-h wrote on 1/19/2019, 3:13 PM

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!

Laptop (Windows 10 64Bit)
Processor (CPU) Intel® Core™i7 Quad Core Mobile Processor i7-4810MQ (2.80GHz) 6MB 
Memory (RAM) 32GB KINGSTON HYPER-X IMPACT 1600MHz SODIMM DDR3 (4 x 8GB) 
Graphics Card NVIDIA® GeForce® GTX 880M - 8.0GB DDR5 Video RAM - DirectX® 11 
Memory - Hard Disk 250GB Samsung 840 EVO SSD, SATA 6Gb/s (upto 540MB/sR | 520MB/sW) 
2nd Hard Disk 500GB Samsung 840 EVO SSD, SATA 6Gb/s (upto 540MB/sR | 520MB/sW) 

Cameras
Canon 5D Mk3
GoPro Hero 4 Black
GoPro Hero 7 Black
Samsung Gear 360
Samsung Galaxy S7

Vegas Pro 16

Musicvid wrote on 1/19/2019, 3:39 PM

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!

dmitry-DS wrote on 1/20/2019, 12:51 AM

https://www.mediaarea.net/QCTools. An interesting program for video analysis. Maybe someone will come in handy.

chris-h wrote on 1/20/2019, 11:59 AM

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!

Thanks

Laptop (Windows 10 64Bit)
Processor (CPU) Intel® Core™i7 Quad Core Mobile Processor i7-4810MQ (2.80GHz) 6MB 
Memory (RAM) 32GB KINGSTON HYPER-X IMPACT 1600MHz SODIMM DDR3 (4 x 8GB) 
Graphics Card NVIDIA® GeForce® GTX 880M - 8.0GB DDR5 Video RAM - DirectX® 11 
Memory - Hard Disk 250GB Samsung 840 EVO SSD, SATA 6Gb/s (upto 540MB/sR | 520MB/sW) 
2nd Hard Disk 500GB Samsung 840 EVO SSD, SATA 6Gb/s (upto 540MB/sR | 520MB/sW) 

Cameras
Canon 5D Mk3
GoPro Hero 4 Black
GoPro Hero 7 Black
Samsung Gear 360
Samsung Galaxy S7

Vegas Pro 16