Crash when testing MakeRuggedTerrain.vuo example

eseftel's picture

Status: 

Vuo version: 

OS version: 

  • macOS 10.14

How severely does this bug affect you?: 

●○○○ — Not much; I'm just letting you know about it.

Steps causing the bug to occur: 

  1. Open MakeRuggedaterrain.vuo example
  2. Edit-Protocol-Image Generator
  3. Connect Time input to MakeNoiseImage Roughness

Crash reports: 

AttachmentSize
Binary Data MakeRuggedTerrain.crash74.65 KB

Possible 'Receive Blackmagic Video' Node issue

Status: 

Vuo version: 

OS version: 

  • macOS 10.14

How severely does this bug affect you?: 

●●○○ — It's annoying but I can work around it.

Steps causing the bug to occur: 

On an extremely complex composition that I can't unfortunatly post I couldn't get 2 Receive Blackmagic Video nodes using 2 Blackmagic UltraStudio Mini Recorders to work in the same composition properly. Watch link below to see an example of the issue. Each BM UltraStudio Mini Recorder has it's own address and can be used in OBS together and usually worked in a much simpler Vuo composition but has issues in the complex composition. What's even stranger is that swapping the BM node out of the receive live video node fixes the issue with nothing else changed so this has to be an issue with the BM node itself I think. Right?

I have tried to create a simpler composition showing the issue but only ran across the issue one other time. However after a reload of that project it started working properly and I wasn't able to recreate the issue on that project again.

Have you found a workaround?: 

Make sure you are using MacOS 10.14.3 or earlier. With nothing else changed I replaced one of the Receive Blackmagic Video nodes for a Receive Live Video node and this resolved the issue.

Other notes: 

Live video crashes/failures in macOS 10.14.4

Status: 

Vuo version: 

OS version: 

  • macOS 10.14

Steps causing the bug to occur: 

In macOS 10.14.4, compositions with a Receive Live Video or List Video Devices node no longer work and sometimes crash.

The underlying problem is that, starting in macOS 10.14.4, a video library that Vuo uses (Apple’s QTKit) is broken. Other apps that use QTKit have also stopped working.

The problem will be fixed in Vuo 2.0, as it no longer relies on QTKit. See our mailing list / blog for updates on the estimated release date.

Have you found a workaround?: 

Downgrade to macOS 10.14.3 or earlier.

Kinect Depth Image Incorrect Greyscale Direction

Status: 

Vuo version: 

OS version: 

  • macOS 10.12

How severely does this bug affect you?: 

●●○○ — It's annoying but I can work around it.

Steps causing the bug to occur: 

Kinect v1 outputs a depth image, great. From the node documentation: 'This is a grayscale image in which closer objects are colored darker and farther objects are colored lighter.' I believe a standard depth image should be the reverse of this, closer objects should be lighter and vice versa.

Have you found a workaround?: 

Yes, invert the colours.

Other notes: 

All the other Kinect apps around output lighter grey as the closer regions.

Vuo using CPU for HAP playback?

conanp's picture

Status: 

Vuo version: 

Steps causing the bug to occur: 

Hello, hoping someone can compare their experience playing back HAP-encoded content in Vuo 1.2.8. I'm finding that Vuo appears to be using CPU for HAP playback on the two systems I have available to test (MacBook Pro with dGPU running 10.13.6 and Mac Pro with GTX 1070 running 10.12.6):

Pretty simple to reproduce, using "Play Movie" node with HAP-encoded movie file as input, then seeing these results on the MacBook Pro:

CPU usage for 2560x2560 HAP-encoded playback: Vuo: 250% VLC: 70% QC with the CoGeHAP Player: 25%

For 1080p content: Vuo: 100% VLC: 35% QC: 15%

Video files are encoded with Apple Compressor, AVF Batch Converter, QuickTime 7 Pro, no effect on the issue. This is my first attempt at using Vuo to replace some utility QC compositions, hopefully I'm missing something or having an issue unique to my setup.

Pages

Subscribe to RSS - Accepted