It’s Officially a 64bit World – Or Is It? 32 vs. 64 bit Transcoding
Published: October 21st 2019
At Cinnafilm, we’ve had 32bit and 64bit versions of our technology for many years, and I figured the question of 32 vs. 64 bit Transcoding was a moot point. Everyone would just choose the 64bit SDK (Software Development Kit), right? Our Dark Energy Professional switched to 64bit years ago, and our SpaceTime library (which contains Tachyon) has been available as 64bit for years…but some companies still used our 32bit SDK for reasons unknown to me.
Please note: RadiantGrid by Cinnafilm has been retired, and we suggest that you now point your attention to Cinnafilm PixelStrings.
RadiantGrid and 32 vs. 64 bit TranscodingThen we purchased RadiantGrid, and I COMPLETELY understood why 32bit was still alive and well in 2017. We weren’t in the transcoding business before acquiring RadiantGrid; I didn’t know about the legacy support of codecs and containers that were only created in the world of 32bit – some in the 16bit world, and they would never be re-compiled to run as 64bit. I did rudimentary research on how many tech-savvy people run a 32bit OS. I found 4.3% of Windows 10 users installed a 32bit version and only 0.002% of Mac users. Digging further, I uncovered Mac users don’t have a choice when updating their OS; it automatically installs a 64bit OS. In 2009, Apple shipped 64bit operating systems that could also run 32bit programs, making a seamless transition to 64bit. So if someone is running an Apple OS that is only 32bit capable, it’s because they have not updated their OS in 9 years. Had they updated, the 0.002% figure would be even lower. So why does Microsoft still ship 32bit operating systems, especially since every 32bit application is fully backward-compatible with 64bit versions of Windows OS? I have no idea. But it has perpetuated the continuation of companies creating 32 and 64bit versions of their technology, and that leads us to the question of 32 vs. 64 bit Transcoding. And that leads me back to when I said, “I COMPLETELY understood.” We have launched a new version of the RadiantGrid transcoding engine. One critical issue our product/engineering team tackled was how we were going to handle legacy codecs and containers that are simply not available in a 64bit architecture. We had two options: write a 32/64bit bridge so this new engine could support ANYTHING ingested and only output video that is generated by a 64bit SDK, or say “no mas” when it comes to codecs/containers that use a 32bit SDK. For the time being, we opted for “no mas.” (for those that don’t speak even a smidgen of Spanish, that means “no more.”) We decided to be future-minded and only support technologies that are based on a 64bit SDK and can support UHD/HDR video on output. With that said, our customers are always our number one focus. We will still consider discussions regarding building the 32/64bit bridge to support legacy codecs such as Canopus AVI or Indeo. We love solving challenges that best serve our clients. For now, we are focusing on the first RadiantGrid build that was fully architected by Cinnafilm. We’ve taken the time to redo a few things, which make it more powerful and flexible than any previous version of RadiantGrid. Some of the cool things you’ll see are:
- Vastly expanded audio channel remapping
- Removal of the need to fully ingest assets before transcoding
- Options for automatically converting 100 nit SDR assets to 2,000 nit HDR assets
- Creation of incredibly complex image processing pipelines that render assets in a single pass for any resolution. In 32bit space, the pipeline is limited to 4 Gig, so we can’t “back the truck up” and load it up with image processing functions when images get larger than HD
- Movement of many functions into the UI that were only XML-submission based