Custom Old Mac Pro Build vs New 2013+ Mac Pro

[Eric Bowen]

FFMPEG does as good a job at encoding ProRes as anyone else. The IP is available and it's not a big deal to implement ProRes in various types of encoder or recording products. Relatively easy and inexpensive to license for that use. However, when it comes to use as a software codec on Windows or dedicated within PC applications, the licensing isn't as easy to get. For some time it wasn't available, however now it is. ...And yet BMD and Adobe seem to be pretending that a huge portion of the industry doesn't want this.

Outputting in DNx and then converting to ProRes is a problem. It still is a transcoding process and while loss is minimal, we still incur further loss and artifacting.

How does exporting DNx 440+ and conversion to Pro Res 444 lower the quality. They use the same compression scheme and both are lossless. If that was the case you would lose quality outputting from DNx 440+ to DNx 440+.

 

[Blair S. Paulsen]

Even if two codecs have theoretically equal performance metrics, encoding from an already compressed format will inevitably result in some concatenation artifacting. I would also note that even if two codecs share a compression architecture, like DCT, there are still variations in how each scheme is employed that may not be obvious visually - but can impact the way that file is interpreted by the next compression engine in the chain.

TIFF or OpenEXR (16 bit) is the obvious mezzanine format for this kind of situation, but it does increase the data load significantly. Some people use CineForm as the mezzanine codec for getting graded material over to a Mac for ProRes encoding. Might be a good "just right" option for some projects as it keeps you out of the data bloat of a 16bit image sequence and has less concatenation issues than DNxXX to ProResXXXX since the compression schemes are fundamentally different (IIRC CineForm is J2K based like RedCode, just different implementations).

Cheers - #19

 

[Eric Bowen]

Got time to test that hypothesis? Outside of mathematical artifacts versus visual I dont see how going from a lower compression higher bit rate to a higher compression lower bit rate degrades the media any more than the higher compression lower bit rate would in the first place with the same block based compression scheme with subtle variations. If that was the case then Cineform would do the same even with Redcode J2K.

 

[Blair S. Paulsen]

The basic theory is that all compression schemes toss some data. When you re-compress, the second encoding process is no longer picking and choosing from the full data set - just the subset that made it through the first encoding pass. The ability of the second encoder to make it's best image is therefore inevitably compromised. As with many of these kind of discussions, there are many nuances (bit rate, how many pixels change from frame to frame, etc) that impact real world results. YMMV.

Cheers - #19

 

[Eric Bowen]

But in the case represented above the frame data from source still exceeds the frame data from render and all frames are represented versus partial frames referenced with other compression types. Along with this similar compression processes are used. So the case should be the final removal would unlikely remove much if any more data than what it would have removed in the first place. Now if a completely different compression scheme is used then I can definitely see the issue with translating frame data again.

 

[Blair S. Paulsen]

I'll concede that the real world artifacting issues when going from Avid's codec implementation to Apple's codec implementation at high bit rates is minimal in most cases. That said, with the kind of bit rates commonly used (DNx36, ProResLT) - then I'm far from convinced that re-encoding decimated frame data will be indistinguishable from encoding directly from the source frame data.

Would be fun to test a signal chain using the top DNxHR codec to ProRes444XQ and using DNxHD/36 to ProRes444XQ and running a difference matte...

Cheers - #19

 

[Eric Bowen]

I absolutely agree with any rate lower than 440 or 444. At that point to much frame data is interpreted on both source and render. But DNx flavors especially HR I just dont see it especially with DNx flavors having more data per frame than the closest equivalent to Pro Res. It would definitely be interesting to test the flavors 440+ to 444 and see what the comparison was to the direct source to 444.

 

[Bryan Matuskey]

I just got a 12 core, 1tb ssd, 64gb ram, daul d700 traschcan and it can't even handle my 4k prores files half as well as my Macbook Pro with less than half the specs. Not sure if I got a bad computer and should return or if nVidia cards make that much of a difference. I saw improved render times, but nothing to be excited about. I love Mac OS, but starting to be tempted towards a custom PC. I wonder if r3d files will perform better than Prores has, but I won't have my new Red Weapon for about a month. Any insight you coupd share would be appreciated.

 

[Jarek Zabczynski]

I just got a 12 core, 1tb ssd, 64gb ram, daul d700 traschcan and it can't even handle my 4k prores files half as well as my Macbook Pro with less than half the specs. Not sure if I got a bad computer and should return or if nVidia cards make that much of a difference. I saw improved render times, but nothing to be excited about. I love Mac OS, but starting to be tempted towards a custom PC. I wonder if r3d files will perform better than Prores has, but I won't have my new Red Weapon for about a month. Any insight you coupd share would be appreciated.

If you just bought new I would return if possible. Next revision is due in June…everyone's best guess anyway. If your Macbook works, use that for a couple more months.

 

[Hal Long]

Agreed. The trashcan is 3+ years old and is long overdue for an update. I'd try to get by with what you can until the refresh.