​[ANSWERED] Using Picture Player with Broadcasters and Listeners

[jfg]

@peuclid

an easier workaround is to put an video effect actor with by pass to on  between the Picture player and the broadcaster

best

Jean-François

[peuclid]

That workaround seems good in theory, but doesn't seem to work for me. I tried several different video filters including Crop and Video Mixer, and it seems as long as the line is red, it isn't passing through the listener when it's on a different scene inside a user actor.

I'm attaching an updated version of my example, this one has a Crop actor between the picture player and the broadcaster. It didn't seem to make a difference when the broadcaster was inside a user actor. It could be something else at this level.

broad-listen-picture.izz

The pieces look like this (I couldn't attach all the images as it complained about being too big)

The main scene (broadcasting), shows a video (channel 11) and a picture player (channel 10) going to their respective broadcasters. (I couldn't attach image here)

A second scene (listener) activates the first scene and has user actors that listen to their channels and output the video (I couldn't attach image here)

The Picture Listener (user actor) looks like this:

Seems simple enough. The one playing the video (same as this but channel 11) successfully outputs the video to the User Output, but the one listening to channel 10, which has the Picture Player, doesn't output anything. Although, I do see that the output is there when I mouse-over the red line from the listener, but it doesn't make it through the User Output to the scene that contains the actor.

[side-note, it won't let me post this with the images as it complains about being longer than 32767 characters]

[jfg]

@peuclid

Ok the same here with one difference: if I direct connect the listener with the projector (not in an user actor) I get first the picture through until I go back to the Broadcast scene and then click on the Listen scene. Then is no picture. I delete the connection linee and make a new oe. the Picture is back. Not a solution.

best

Jean-François

[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 :)