Remote broadcast monitoring for Flame

Sysadmins Remote Workflows
1

We’re currently getting set up for our Flame artist to go remote while keeping his Flame hardware here on-prem. Set up as follows:

We have a Flame user at our studio who is moving across the country. Our plan is to keep his system in place here on-prem and have him remote into it to work.

Host system (on-prem here at the studio):

  • Rocky Linux 9.3 Flame on a 3090 Ti
  • 2x 2560x1440 GUI monitors
  • Running NoMachine Server for GUI hosting
  • Keyboard/mouse/Wacom
  • BlackMagic Decklink output to 1x broadcast monitor (unsure what resolution, but at least 2k)

At home the remote user will have:

  • a M4 Mac Mini or M1 Mac Studio
  • 2x 2560x1440 GUI monitors with NoMachine receiving individual windows per display, which he can full screen on each so that it’s quite seamless
  • Keyboard/mouse/Wacom
  • And a separate mini PC running Rocky Linux as a broadcast receiver, attached to 1x reference monitor

The thought behind the separate miniPC for a stream receiver was to keep the GUI session as 1:1 as possible between the host/client systems to minimize any oddness happening with NoMachine. So far NoMachine has been working well for GUI.

However, we’re in need of a graceful solution for getting his Flame output to his remote system, with as little latency as possible while retaining good image.

A few ideas I’ve been pointed to are Flame NDI > BirdDog NDI decoder and ffmpeg screen scraping > RTMP > Ant Media Server. I know Blackmagic has encoder/decoder hardware as well. We’ve been able to install obs-studio on Rocky but it’s not playing nice with NDI.

Does anyone have experience using any of these solutions for something like this, or can suggest additional avenues to pursue?

2

Search the forum. So much discussion on this. Your solution is non-optimal.

1 Like
3

Ultragrid is hard to ignore and been discussed quite a bit.

4 Likes
4

I doubt you’re wrong, however my search yielded myriad results for GUI solutions and wasn’t finding many for Linux-hosted output monitoring. I’m new here so still getting the hang of things.

5

Thanks, I’m looking over this now. Looks like both you and @ALan speak highly of it which speaks volumes.

1 Like
6

@john-geehreng has written some clever glue as well which can help ease the automation aspect. It’s available on @MikeV’s logik portal.

3 Likes
7

Yah currently the best and only real way is PCoIP via HP Anywhere and Ultragrid for broadcast.

3 Likes
8

this is quiet the flashback to covid days :smiley:

Please dont let anyone use nomachine for actual work, as randy said get hp anyware going and then ultragrid for broadcast.

5 Likes
9

We use nomachine on our linux machines to remote into mac minis for photoshop. It is not color accurate at all. The color temperature of the signal changes constantly while using it. Would not recommend for Flame work at ALL.

2 Likes
10

IT…
Can’t live with 'em
Can’t leave them at the mall by mistake…

2 Likes
11

To those lamenting NoMachine: I get it! But without a workstation graphics card (and being on Linux), my understanding is we’re out of luck when it comes to HP Anyware. Am I wrong? Is NICE DCV enough of an improvement over NoMachine to warrant a switch? Rhetorical question—I’m sure the forum already has that verdict somewhere I can suss out.

As for the topic at hand, we’ve successfully started testing UltraGrid for broadcast streaming with a huge head start thanks in large part to @cnoellert. A key enlightenment was the bit rate notation, i.e. using 40M. We had started with 2500 (assuming it was kbps) but I’m guessing it was treating that as bps and is why our initial compression tests looked awful except on ProRes.

I have noticed that when my Mac test receiver is being targeted by an active stream, I cannot launch the uv-qt GUI without it immediately crashing. Instead it needs to be launched from CLI, i.e.:

/Applications/uv-qt.app/Contents/MacOS/uv \
  -t ug_input \
  -d vulkan_sdl2 \
  -r coreaudio

Is this experience common for others?

12

In the terminal, if you do a:

sudo sh /Applications/uv-qt.app/Contents/MacOS/update.sh

…then uv will update in-place and you should be off to the races. There are issues with certain versions of Mac OS and the update seems to temper that. It needs to be the absolute path to the update though–you can’t run the script with a relative path just FYI.

1 Like
13

When it comes to techie details of this stuff, I’m not even in these guys league and I’m not really sure of they type of work you do, but, I would consider installing flame locally on the Mac, connect to the studio’s network through VPN for moving footage back and forth or use a service like Lucid, and use any of the common remote viewing services at the studio. I don’t know where they are moving to or what the bandwidth is like there, but with this method you don’t go totally down if there is an interruption of service. I use HP Anywhere to connect to my Linux machine a few blocks away. I have fiber with 10g ethernet and my signal only goes across town, but on occasion I lose connection or it gets sluggish and funky. It can be very frustrating working that way. And restarting the machine remotely late at night is dicey.

2 Likes
14

Yeah very good point, and not one we’re not thinking about. I have a feeling that’s where we’ll end up so we’re going to try Amove Click out, to allow the user to work from directly or cache from our Facilis SAN volumes to local drives on-demand. That’s the idea, at least.

If that ends up being the preferred method of work for the user I’d end up needing to send him along with something beefier than an M4 Mac Mini!

15

Indeed, you would need the Mac Studio.

1 Like