​[ANSWERED] Using Picture Player with Broadcasters and Listeners

[peuclid]

@jfg

Thanks for all the help.

I just cleaned up the example and included a sample image (screenshot from troikatronix site) and put broadcasters/listeners in the same scene. It seems to work sometimes, but then stops when the screen gets inactive and then active again. I'm working around it for my real project by using a 1-frame video, so this isn't urgent for me anymore but more of a heads-up that there seems to be a possible bug somewhere.

izzy-broadcast-bug-example.zip

[jfg]

@peuclid

I get it to work with a strande workaround:

but it stays a bug

best

Jean-François

[peuclid]

@jfg

Yes, it does feel like it just needs a change/trigger of some sort to keep it alive. Thanks for finding that.

[DusX]

@peuclid

my usual approach:

This approach grabs the input image at the framerate and converts it to a video stream. This method works well for situations where you might be changing/mixing the input image, but in most cases you could just connect the Picture Player trigger output to the grab input of the Freeze actor (removing the Pulse Generator) and reducing the grab actions which might very slightly reduce cpu usage.

and without Pulse

[Woland]

@peuclid said:

Even the lines are green which makes it possible to see that it's actually working.

This is actually not a bug, and is the expected behavior. A broadcaster sends data when it receives data. A Picture Player sends one frame when you change its input or enter the Scene in which it is present (so the line will be green during either of those actions, then red, because it's not sending any other frames). So if one of those two actions is not occuring, the line will be red and the Broadcaster won't receive a frame to send to the Listener. A picture is not a video, so is not does not send a continuous stream of frames.

Think of it like this:

You'll notice that @DusX 's solution is basically like taking the Wave Generator and connecting it to the Calculator so that it's constantly sending data.

[liminal_andy]

@woland would the trick of attaching the default GLSL actor between the picture player and the broadcaster be a one-actor solution for Bernie?

[Juriaan]

@liminal_andy

This is an perfect solution for OP.

Attaching a GLSL shader with the default code will force the output to be a steady video signal instead of only one frame (like an image is)

[peuclid]

@Juriaan 

Ah a default shader that just passes through seems like a simple one. I'm try that. If not, I also like the pulse generator approach that sounds like a film projector flashing the same frame over and over. 

I did my workaround so am not too concerned, but this is all really good to know and to have this thread for future searches.

[peuclid]

Battle of the broadcasters! When broadcasting a Picture Player, the ones that work are the default GLSL Shader and the Pulse Generator.

[DusX]

@peuclid

Note the final image where you say 'NO' in your comment works with the addition of a Trigger delay (sorry I missed that).
This will ensure the loaded image is pushed into the Freeze, and that any updated Picture is also updated.
This method with the freeze is what I have been using for years (we didn't have GLSL at that time), I don't know if there is any performance benefit?
It does seem the default GLSL is the easiest approach :)