FLAME-ON-MAC: Remote client screening setup?

Ultragrid seems really neat but is there any sort of additional documentation?

Even just copying and pasting the command from the tutorial they link to for sending a testcard to myself I get the error: Multiple receivers given!

For reference this is the command:

./uv –t testcard:1920:1080:30:UYVY –c libavcodec:codec=MJPEG –d gl 127.0.0.1

I’m presuming there is actually something wrong in there but I can’t see it and the only place google finds that error message online is the ultragrid source code.

Your dashes were wrong… they were em dashes, so they were all being read as destination arguments.

try:
./uv -t testcard:1920:1080:30:UYVY -c libavcodec:codec=MJPEG -d gl localhost

While you’re learning you can always launch the gui, with uv-qt and play with the arguments at least on a Mac…

Otherwise for more information you can always check the wiki which very well be the place you’re finding the tutorials. It’s a great resource →

…the discussion section is fairly active and I’m sure you’ll find some familiar names asking questions and reporting bugs.

One thing to keep in mind with UG, is that currently when using a compressed format which results in small data rate, the FEC isn’t really effective. This is why use SRT as a transport mechanism. In Chris’ case, he is streaming Prores, which has a very high data rate, and with that the FEC is highly effective.

1 Like

Well that’s I get for copy and pasting I guess. Lazy monkey should just type it out.

Thanks!

1 Like

Reviving this to say that I ran Flame 2025 NDI to Ultragrid ALL in an AWS instance today.

Client-side, I used the -N nat traversal flag so that the instance didn’t need to be on our Tailnet and pushed hardware encoded H265 out at 20mbit to the client machine which ran the signal out to broadcast over a BMD Ultrastudio. Looked great once I figured out how to stop the pulsing when parked on a still frame.

It’s nothing that we haven’t talked about before, but it’s the first time I’ve done it with cloud infrastructure and given that data-rate man it looks really good.

Are other people just using commercial products to do this stuff in the cloud? Everything I could find on CDI looks like it’s instance to instance…

3 Likes

NDI as input to UG?
Were you using NVenc?
What resolution?
What latency?
The GOP pulse is super annoying. Had many discussion with the UltraGrid team about it. Apparently the FFmpeg implementation of NVenc doesn’t respect intra-refresh, but things could have changed in the past year or two that I tried.

The challenge with H.265 is UHD resolutions. Anything below UHD, is easy with a modern processor. I’ve recently come up with a few x265 parameter settings that allow me to get UHD RGB:4:4:4 12bit consistent @24fps on Ryzen 9 7950X. I feel like I finally got the holy grail. Been trying to do that for years. All other products convert to YUV.

1 Like

Yes, NDI to UG. Needed the SDK libs but once they’re in place it works. Using Nvenc…

[NDI cap.] Received video changed: 1920x1080 @23.98p, codec Y216

Latency wise it’s bananas:

Regarding the pulsing this little gem did indeed solve it:

--param lavc-rc-buffer-size-factor=0
3 Likes

That latency is great. Although, Teradici/NiceDCV could be adding a frame or two of latency itself, making the apparent latency of UG feel a tad better.
Are you doing any packet loss mitigation?
Are you running UG on the same machine as Flame?
Since you are doing HD YUV4:2:2, you could encode all in CPU and skip the GPU.

I’m guessing there’s at least one frame delay on the gui but the latency “feel” of the whole setup feels almost as fast as “in the bay” which is huge.

It’s running with ReedSolomon so we’ll see what that means with such a significantly lower data rate and it is indeed running on the same instance as flame.

I’ll definitely give cpu a try next.