Today with recorded the premier episode for this season of Studio Hockeyettan. For the new season we did some updates in the "studio look". How it turned out can be seen at Hockeyettan's Play channel. Fast forward 3 minutes to see the effects I am discussing here. (eagles might notice that we forgot to tweak the chroma on the wide shot...)

Anyway, there are two issues we ran into. But before that, this is how we set it up:

The desk monitor Input is created by a Colour Input (transparent) with MultiView:
- Layer1: Photo Input containing the table images on MultiViev
- Layer2: Image Input with the tv frame image.
This means we can present the tables in full screen without the frame.

The "wide shot" is created with a Colour Input (transparent) with MultiView:
- Layer1: An Image Input (the camouflage blue)
- Layer2: Camera Input, chroma keyed
- Layer3: desk monitor Input


The first issue was expected, and is already discussed elsewhere. We could not use the Merge to zoom the "desk monitor" into fullscreen due to how we order layers. How this Merge would have looked like can be seen in this short demo, passord "merge". To solve this problem I have earlier published a Feature Request for rearranging layers.

The second issue is more puzzling. It seems to be limitations when using MultiViews as layers in another MultiView. See attached image for a vMix screen shot. As can be seen in Output the left "box", which is layer "CAM2", looses the desk monitor. Earlier we have found other strange behavior, like a layers zoom, pan, and rotation settings are mangled when used in another MultiView.

One would assume that MultiView Inputs could be treated as any other Input, eg for another MultiView's layer. Apparently this is not so.

Anyone else have had similar problems? Could this be a limitation of what Windows can handle in term of video layers? Or, are we simply doing something wrong?

The second issue is more puzzling. It seems to be difficult to use MultiViews with other MultiViewed inputs as layers. See attached image for a vMix screen shot. As can be seen in Output the left "box", which is layer "CAM2", looses the desk monitor. Earlier we have found other strange behavior, like zooming and rotation settings become mangled when used in another MultiView.

One would assume that MultiView Inputs could be treated as any other Input, eg for another MultiView's layer. Apparently this is not so.

Anyone else have had similar problems? Could this be a limitation of what Windows can handle in term of video layers? Or, are we simply doing something wrong?

Ah, if I got your memory serving right, the trick might be to use eg layer 1,2 in the first MultiView, and then 3,4,5 in the second. (asking, cause it's kind of weekend now and I can't try).

Hi Richard,

The concept of using a MultiView within another MultiView is called "re-entrancy" in the broadcast world and in vMix this is only supported twice.
So if you have a MultiView within a MultiView that will work fine, but if the second level MultiView also has MultiView inputs these will not render.

Also, regarding merge layers, that is a good feature request to quickly move around the orders in Input Settings.
However the Merge transition will always follow the order of the layers.

The effect shown in the video you posted on Vimeo is logical. Because the TV is on top of the actual video, it needs to fade away.
Adding any other options or scenarios is just far too confusing, both from a support perspective and also for customers.

Regards,

Martin
vMix

So, we reorganized our setup to use only one re-entry. But then we ran into a couple of issues that are demonstrated in a short video.

To begin with, although this might be advanced stuff. I believe that most users expect a MultiView layer to appear as its original Input does. Of course after adjustements to the layer's settings. But as can be seen 00:30 in the video, the tv-frame grows out of its box. Ideally vMix would crop at the zoom-level. In some cases we can work around this and instead of a background image use a top layer image with holes for the boxes. But then we could not zoom/pan/rotate the box. The current behavior could also be a challenge for the "soft pan/zoom idea" (discussed elsewhere) in a Camera Input that is used in a MultiView (which probably is a dominant need).

Second, and I really hope this is a bug that can be fixed ;) From 00:40 and onwards we can see that zooming and panning the tv-frame layer in the original Multiview (Input 3) works fine. But rotating the X and Y axises does not work. Same thing goes if the Main level is rotated. After some experimentations it seems to me that the problem occurs when the layer in the second MultiView (Input 5) has been panned.

Ice,
Thanks for your comments.

I uploaded a zip-package with the demo preset and images so that you and other people can try for yourself. Either install it in c:\MultiView or some other directory and upon loading the preset simply browse to select the new images locations. (Other images as I am not allowed the publish the ones used for the video I made).

In that Preset I added an Input with an image (3840x2160) larger than the Production (1920x1080). Then added that input as a MultiView layer, cropped and rotated, on the yellow image. Just to illustrate my points here.


Regarding 1:

I don't know how vMix is designed. But I am impressed by it, and love to stress vMix's limits to create productions that suprise our customers ;) Sometimes experiments like this result in behaviour that I guess Martin is the man who can see the full picture and act accordingly.

My point is that I sort of assume that what I have created in an Input, in this case a MultiView (Input4) should appear like I have created it when that Input is used in another MultiView (Input 5). Likewase, consider if one would create a MultiView input that use the envisioned x-y image movement (I called it "soft pan zoom", daniel514 calls it "virtual cameraMAN"). Then if that Input would be used in another MultiView (eg a double box combining a presenter and powerpoint slides), it should not be mangled (sorry for the wording).


Regarding 2:
Could you try with the Preset I uploaded? I have the same issues on both nVidia and Intel's built in graphics. And see the same behaviour both while altering and when the Input's settings window is closed.

Hi Guys,

This is easy to experiment with using only a single input:

1. Add Colour Bars Input
2. In Input Settings -> Position, rotate it around the Y axis to a value of around 1.
3. Now pan it from left to right and notice how it shifts angle.

It seems wrong, but this is how perspective 3D works, just like how if you would
look out a window from a distance and move left to right the items and angles viewable outside the window would be different.

Now, in the case of MultiView this could be avoided by rendering the entire input first
as a 2D graphic and then simply placing it within the MultiView input in the new position.

The challenge is, peformance wise this can be significantly slower than just rendering the entire MultiView scene in one pass!
Certainly this is something we could look at adding, but how useful would it be considering it has worked like this for years
and is only now being discussed ;)

Regards,

Martin
vMix

Martin,
Thanks for the clarification.


Yeah, I understand that. Let's say we have one MutiView (A) that is used as Layer X in MultiView (B). I figure that for Layer X the Point-of-View is B's, not A's. That is why the perspective is overdone ("mangled")
If so, would it not be possible for vMix to compensate the Layer X pan settings in order to maintain A's POV? That is, ie the pan Settings for Layer X are adjusted "behind the scenes" before B is rendered.

Sure has worked for years. But maybe those who experimented before me gave up, or never asked.

In any case, from my POV (haha!) I've said enought on this matter for the moment. Glad to help if you go ahead with this in the future.

Have a fab weekend - you're worth it!