Burn - ON MAC!

Hello All,
Please dont shoot me but I’m looking at trying to get ‘some’ kind of burn farm going within a Mac only studio.
I had already tried to setup a linux Burn node but was denied due to this studios main shared storage only supporting Win/OSX :man_facepalming:t6:
(uses a s/w client to manage SMB shares and the actual NAS is native Windows)

I’m going to test the following:
MacMini / Studio
Flame subscription

The Mini should be able to act as a burn renderer, as that’s what they all use in the ‘background’ as a foreground but has anyone else ever bothered to give this a go?

Cheers,
Brewster

There is no Burn on Mac. Dead end.

If your NAS is a Windows machine, it very likely serves up via SMB which is certainly compatible with Linux. Sounds like either your IT department is incompetent and doesn’t know what they are talking about, or lazy and doesn’t want to deal with it. Often those 2 traits are symbiotic.

Not for nothin’ but I made a setup on Linux that I then had to re-render on mac. It came out different. A bunch of levels on some elements looked like they got clamped. When I was able to render again on Linux it matched the original. It was done under pressure, so I didn’t really investigate since I wasn’t planning on using the mac again any time soon. It would make me wary of creating on one platform (mac) and burning on another (linux).

Good luck mate.

I’d love to hear how this goes.

1 Like

Cheers ALan, I am my IT dept (been working with Flame since it started on Inferno on Onyx1’s)…
:wink:

Will let you know Rich.
I have a feeling its going to involve using a Flame license on the ‘burn’ node so it wont be a free solution but if it works then its a price some companies might pay to increase Ops productivity…

Will let you all know
Cheers
B

Several years ago, I had a burn machine setup to support two suites (one Flame, one Smoke/Flame Assist). It worked really well but definitely had some caveats.

The burn machine was, of course, Linux. Because that’s the only place burn will work. So, you have to consider that in your plan. The maintenance and general upkeep of a Linux box can be a real hurdle if you aren’t used to it. And it can’t really be a super cheap Linux PC - you have to use a GPU that Flame supports, which can be more than the cost of the PC itself. So keep that in mind as well. Think of burn as a headless Flame, with many of the same requirements.

My Flame box at the time was also on Linux, while the Smoke/Flame Assist box was a Mac. Everything was connected via 10gbe and performance was good for what we were doing, which was HD finishing. The burn box was an older Linux machine (actually, our first Smoke Advanced box that was orphaned when we got a new Flame setup) so for many things a local render was faster. BUT… If you had timeline work to do, such as color grading per clip or rendering supers, you could march right down a timeline, sending the renders off to burn and never have to stop. The renders would eventually catch up and things were good. Or if you had a batch that you knew was going to be several minutes to render locally, you could send that off to burn, where it might take 10 minutes, but it kept your local machine free to continue doing other things, which was great.

I don’t know if it is still the case, because I’ve since moved on from that setup, but it used to be that Flame came with complementary burn licenses. At least with Flame Premium it was effectively an unlimited number of burn licenses so you could setup multiple burn nodes if you wanted and it didn’t cost more than what you already spent on Flame. But I’m not sure it is that way any more - I’m sure others here could fill you in on the licensing part of things.

-Matt

May be misunderstanding your post, however, the documetation states that the following components do not require a license:

  • Wiretap Gateway
  • Burn
  • Lustre Burn
  • Lustre SR
1 Like

Brewsta!!!

This was asked locally here at NAB and Autodesk doesn’t think it’s possible. An eBay special P620 can be had so cheap I don’t think this is ever gonna be worth it.

Cheers Randy.

I absolutely agree and I did build this client a Linux burn node but the issue is their NAS provider.
They only support Mac/Win and as I mentioned earlier, even though the underlying fabric is SMB, the way they manage the system means that a Linux box can’t see the shares correctly.
So the options are to either explore this, and perhaps pay for a monthly Flame sub, live with no background render or replace the entire storage system…
And as far as I’m aware the NAS is staying :wink:

I only work with this client bi weekly but I’ll let you know how it (slowly) goes

B

Hmmm.

I don’t know man. That sounds rough. I can’t think of a way that would make sense.

Crazy ideas/dumb ideas that probably won’t work.

Direct connect a burn node to a Mac. Can you mount a volume through a Mac on a Linux box?

Put the Linux box on its own network and selectively use something else like a dumb r sync or Lucid or Tailscale or some other way to sync or sym link certain files to the Burn node.

AWS Burn node?

Buy faster Macs?

1 Like

Burn can be configured to use the Flame host for all data transfer. In theory you should be able to have a Linux Burn machine with no NAS connection still render using the Flame host for data.

If your material was imported through a Mac gateway this wouldn’t be an issue.

The burn nodes can see the Mac gateway, the Mac gateway can see the server.

Much in the same way as when you import material from a gateway Mac with a portable drive of rushes sitting on it.

In this instance you might set up a Mac mini as a gateway, import all material through that gateway and then you should have no issues—it is an extra hop of course but if you’re caching media then it shouldn’t be that huge of an issue—more like a temporary wave of inconvenience.

As long as that Mac mini was attached the NAS the rest of your adsk infrastructure could be Linux if you wanted.

@ALan is right as well. That’s another option.

Cheers all,
More options to test than time with the client…
One day every fourteen!