logo

Live Production Software Forums


Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
David_in_Philly  
#1 Posted : Saturday, May 26, 2018 4:55:28 PM(UTC)
David_in_Philly

Rank: Advanced Member

Groups: Registered
Joined: 11/21/2017(UTC)
Posts: 123
United States
Location: Philadephia, PA

Thanks: 31 times
Was thanked: 13 time(s) in 8 post(s)
I'm a huge fan of Vmix and am completely enamored of Multi-View. The problem is, this relationship is sometimes a love/hate affair.

I feel a bit like I'm looking the proverbial "gift horse in the mouth" in offering this point of view and these suggestions on a feature set that delivers so much value for the dollar already. Martin has done an awesome job delivering what we have so far, but IMHO, it could operate more simply and completely. Lets see what my comrades-in-arms here think.

My goal is to mimic the look of cable news network remote panel discussions with up to 8 remote panelists participating through Vmix Call.

One of the great things about merge transitions between multi-views is that it allows the viewer to readily track the participant who is talking among a number of on-screen participants as we dynamically transition to a single participant view or rearrange the on-screen participants to enlarge the one speaking, add or drop out others, etc. There's also a certain joy in watching that transition happen. Here's what it currently takes to do that (with a 1 or 2 pixel border on each image):

- One input for the original source (i.e. a Vmix Call)
- One color input (or looping video) with that call input on top of it (multi-view), slightly zoomed-out, to reveal 1 or 2 pixels - this for a full-frame image with border
- One or more alternately cropped versions of the input above (so, another input for each crop)
- One input for each layout of participants; perhaps some with all 8 and some with fewer and some with alternate sources, like a video of what they're talking about.

With me so far? That's already a lot of inputs - especially as you add more layouts. Now let's add an additional variable, what input we're transitioning from or to (full frame). To look right, the input you're merge transitioning from or to should be at the highest number in the multi-view. That doesn't seem like such a big deal - unless you're trying to build a library of templates so that, without knowing in advance, you can transition to any participant necessary. It seems to me that a common, cohesive multi-view naming strategy is called for, perhaps like:

8A-1T where "8" refers to the number of inputs, "A" is layout version A and "1T" is for input 1 being is on top (the highest multi-view number) - which would allow transitions from or to that input. SO "8A-8T" is the same layout but with the input in multi-view slot 8 is on top and will remain so during a merge transition to that input as full frame or an alternate position. Keeping count? That means, in this case, 7 additional virtual multi-view inputs in order to support possible merge transitions for each input - multiplied by however many multi-view layouts you need - yikes!

The idea of setting these up on-the-fly during a live webcast scares me - especially since they have to be tested live because they transition from "Preview" to "Program." So, we'd instead most likely want to set them all up in advance; which means lots and lots of inputs. I've also learned (thanks, Martin) that how the border colors move (under the on-screen multi-view inputs) during merge transitions is dependent upon whether the inputs were created from scratch or created as virtual copies).

So, what might be done about this? I'm not a developer and don't know if the current architecture will even support this, but...

1. If the ability to create a color or video border (of "x" width & type - like beveled) could be moved to each of the 10 layers in a multi-view; within the bounds of the current frame, it would remove the necessity to create one or more inputs just to support borders - and the border motion during a merge transition would be locked to its corresponding input.

2. Along with #1 above, this would also likely mean that we wouldn't need a separate input for each additional cropped input to support each multi-view layout.

3. There are likely several ways to deal with the need to have a different version of each multi-view layout to support merge transitions to each input within it:

- Add "intelligence" that looks at which input is in preview and automatically put that input (in the multi-view) on top just before the transition begins.

- Create a "Merge-2" transition that manually does what the "intelligence" option above does

- Treat the selection of which layer of a multi-view is on top similar to the way we can select which of several text overlays are used from within a single input; with a right click selection (among input names and numbers used in the multi-view)

4. One of the related issues that I've run into is that after the cropped positions are all created, a camera or laptop moves slightly - putting the participant off-center within the box. If we can't easily move the camera or laptop, it would be great to be able to re-position that participant with controls (and shortcuts) for that input - but only within (or under) his multi-view layer. We can already do this if the input is, for instance, 4K and we're working in a 1080 preset - but only on the input itself.

Looking forward to thoughts from the community. Please add a "+1" if you agree.

Thanks.

-David
thanks 2 users thanked David_in_Philly for this useful post.
Ario on 5/27/2018(UTC), CamStol on 11/19/2020(UTC)
robert5521  
#2 Posted : Saturday, July 18, 2020 6:30:08 PM(UTC)
robert5521

Rank: Member

Groups: Registered
Joined: 6/1/2020(UTC)
Posts: 27
Spain
Location: Spain

Thanks: 1 times
Was thanked: 7 time(s) in 4 post(s)
Hello,

Great overview. Have a look at this project. Do you think it implements all you've said?



Not sure how they do it, though? Virtual inputs? Triggers?
doggy  
#3 Posted : Saturday, July 18, 2020 6:48:22 PM(UTC)
doggy

Rank: Advanced Member

Groups: Registered
Joined: 12/27/2012(UTC)
Posts: 5,057
Belgium
Location: Belgium

Thanks: 283 times
Was thanked: 916 time(s) in 755 post(s)
Originally Posted by: robert5521 Go to Quoted Post


Not sure how they do it, though? Virtual inputs? Triggers?


multiple multiviews (copies of one another layers rearranged, 96 in total) and merge quickplay settings for those inputs/multiviews, that's ít
robert5521  
#4 Posted : Saturday, July 18, 2020 9:01:44 PM(UTC)
robert5521

Rank: Member

Groups: Registered
Joined: 6/1/2020(UTC)
Posts: 27
Spain
Location: Spain

Thanks: 1 times
Was thanked: 7 time(s) in 4 post(s)
Originally Posted by: doggy Go to Quoted Post
Originally Posted by: robert5521 Go to Quoted Post


Not sure how they do it, though? Virtual inputs? Triggers?


multiple multiviews (copies of one another layers rearranged, 96 in total) and merge quickplay settings for those inputs/multiviews, that's ít


Thanks, but would you mind clarifying these:
- How can you set quickplay as default behaviour when I click to an input?
- How is he using Virtual input in this scenario?
- The merge transition applies an undesired crossfade effect that I don't see here
- How does he handle the white border in each vmix call?

Thanks a lot!
robert5521  
#5 Posted : Saturday, July 18, 2020 9:14:38 PM(UTC)
robert5521

Rank: Member

Groups: Registered
Joined: 6/1/2020(UTC)
Posts: 27
Spain
Location: Spain

Thanks: 1 times
Was thanked: 7 time(s) in 4 post(s)
- How can you set quickplay as default behaviour when I click to an input?

Input > General > Mouse click action > Quickplay

doggy  
#6 Posted : Saturday, July 18, 2020 9:38:50 PM(UTC)
doggy

Rank: Advanced Member

Groups: Registered
Joined: 12/27/2012(UTC)
Posts: 5,057
Belgium
Location: Belgium

Thanks: 283 times
Was thanked: 916 time(s) in 755 post(s)
General: Settings -> Options - Quickplay transitions - Merge
Input: General - mouse Click Action - Quickplay

as to handling the white borders , it look's like most are just part of the individual presenters input as switching from a multi presentersshot to individual with just a fade ( but using the merge command) from a multiview to a single input which is different going from one MV to Another with all the same layers like here



( frame is a colord rectangle behind the speaker)

Here goiing from multi to single etc ALL multiview merging





Top ROW does NOT have the same Inputs layers as the bottom row . For nice animated merging between them they should all have the same layers even if they are not visible
That being said , it can that they are there but are made transparent to avoid the crossfade effect

Multiviews.JPG (166kb) downloaded 12 time(s).



Edit: watch the video in slowmotion ! Borders are part of the background

crossfade.JPG (46kb) downloaded 6 time(s).
robert5521  
#7 Posted : Saturday, July 18, 2020 11:12:06 PM(UTC)
robert5521

Rank: Member

Groups: Registered
Joined: 6/1/2020(UTC)
Posts: 27
Spain
Location: Spain

Thanks: 1 times
Was thanked: 7 time(s) in 4 post(s)
No, the borders are not always part of the background. Please check at 9:18. The border is already embedded in the vmix call as it zooms out.

And 1:18 we can see that the the border is already present in the input.

If it is already in the input, why when he switches to that input at full screen, the border is not visible?

We are missing something I think...
doggy  
#8 Posted : Saturday, July 18, 2020 11:26:22 PM(UTC)
doggy

Rank: Advanced Member

Groups: Registered
Joined: 12/27/2012(UTC)
Posts: 5,057
Belgium
Location: Belgium

Thanks: 283 times
Was thanked: 916 time(s) in 755 post(s)
Be aware that each series of views , fullscreen, partial screen , all of them etc are a full set of different inputs !
the moment you are pointing : if you have the single person with a border( extra layer) its just a zoom of the complete input including that border ( be it tiny borderline layer or a colored rectangle behind it )

there is no magic involved
when one starts to crop and resize then some magic needs to happen , but in this case its just another layout with another border background . The merging is so quick one doesn't notice the tiny borders fade in the transition

BTW the background is a image layer and another image layer holding the borders everywhere the presenter is not standard 16:9 view

Tell me otherwise (unless its a PIP overlay ) how you would add one currently to a input (video,vCall etc) . am all ears

Am not willing to buy that set just to see how the borders are made in another way at all . v24 isnt out yet ;-)
richardgatarski  
#9 Posted : Saturday, July 18, 2020 11:26:40 PM(UTC)
richardgatarski

Rank: Advanced Member

Groups: Registered
Joined: 2/18/2014(UTC)
Posts: 1,811
Location: Stockholm

Thanks: 137 times
Was thanked: 292 time(s) in 246 post(s)
My guess is that the border is added as a mulilayer to the input, which in turn is zoomed in so that the border is outside of the viewable area.
(at least that's how we do it.)
doggy  
#10 Posted : Saturday, July 18, 2020 11:29:37 PM(UTC)
doggy

Rank: Advanced Member

Groups: Registered
Joined: 12/27/2012(UTC)
Posts: 5,057
Belgium
Location: Belgium

Thanks: 283 times
Was thanked: 916 time(s) in 755 post(s)
Originally Posted by: richardgatarski Go to Quoted Post
My guess is that the border is added as a mulilayer to the input, which in turn is zoomed in so that the border is outside of the viewable area.
(at least that's how we do it.)


exactly Richard

doggy  
#11 Posted : Saturday, July 18, 2020 11:30:40 PM(UTC)
doggy

Rank: Advanced Member

Groups: Registered
Joined: 12/27/2012(UTC)
Posts: 5,057
Belgium
Location: Belgium

Thanks: 283 times
Was thanked: 916 time(s) in 755 post(s)
Originally Posted by: robert5521 Go to Quoted Post


We are missing something I think...


yes the $200 to buy the set and check it all out ;-)

robert5521  
#12 Posted : Sunday, July 19, 2020 12:31:21 AM(UTC)
robert5521

Rank: Member

Groups: Registered
Joined: 6/1/2020(UTC)
Posts: 27
Spain
Location: Spain

Thanks: 1 times
Was thanked: 7 time(s) in 4 post(s)
Originally Posted by: doggy Go to Quoted Post
Originally Posted by: richardgatarski Go to Quoted Post
My guess is that the border is added as a mulilayer to the input, which in turn is zoomed in so that the border is outside of the viewable area.
(at least that's how we do it.)


exactly Richard



Yes, that makes sense.

Originally Posted by: doggy Go to Quoted Post
Originally Posted by: robert5521 Go to Quoted Post


We are missing something I think...


yes the $200 to buy the set and check it all out ;-)



So true ;)

The answer is in the small details. Thanks everybody for your help!
robert5521  
#13 Posted : Sunday, July 19, 2020 6:36:20 PM(UTC)
robert5521

Rank: Member

Groups: Registered
Joined: 6/1/2020(UTC)
Posts: 27
Spain
Location: Spain

Thanks: 1 times
Was thanked: 7 time(s) in 4 post(s)
Please, have a look at this tutorial. It adresses several issues discussed previously:
- Border issues
- Overlapping issues when doing the merge effect

thanks 4 users thanked robert5521 for this useful post.
doggy on 7/19/2020(UTC), CamStol on 11/18/2020(UTC), Reinaldo on 6/26/2021(UTC), David_in_Philly on 7/2/2021(UTC)
Joeboe  
#14 Posted : Tuesday, June 22, 2021 3:39:26 AM(UTC)
Joeboe

Rank: Advanced Member

Groups: Registered
Joined: 4/16/2017(UTC)
Posts: 578
Location: jamaica

Thanks: 77 times
Was thanked: 32 time(s) in 31 post(s)
I tried this, and it only seems to work with the top layer in my case.....none of the others worked....still the same
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.