[FS-9906] Member join/part in conference shows webcam briefly during slide transition Created: 02/Jan/17  Updated: 04/Jan/17  Resolved: 04/Jan/17

Status: Resolved
Project: FreeSWITCH
Component/s: mod_conference
Affects Version/s: 1.9
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: John Briscoe Assignee: Mike Jerris
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Debian 8 / Jessie

Attachments: File PNG Issue Screen Recording.avi     XML File conference.conf.xml     XML File conference_layouts.conf.xml    
CPU Architecture:
x86-64
Kernel:
Linux
uname: Linux qa-fs-me-03 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
Userland:
GNU/Linux
Distribution:
Debian
Distribution Version:
Debian 8 jessie
lsb_release: Distributor ID: Debian
Description: Debian GNU/Linux 8.6 (jessie)
Release: 8.6
Codename: jessie
Compiler:
gcc
Compiler Version: gcc version 4.9.2 (Debian 4.9.2-10)
FreeSWITCH GIT Revision: 7e24a79580a79016e5830948a89e5b5c03820069
GIT Master Revision hash:: 7e24a79580a79016e5830948a89e5b5c03820069

 Description   
Start a conference
Begin playing image(s) while other attendees join the meeting and share their webcam
Conference host advances to the next image

This causes the webcam feed to briefly display on the canvas before displaying the next image.

 Comments   
Comment by John Briscoe [ 02/Jan/17 ]
Just to be clear - we are playing an image, then stopping, then playing new image is what is being referred to by 'advance to the next image'

This seems to be related to a layout change occuring between the stop and the next play being issued. We are not sending any layout change commands.

Nothing occurs when another caller initially joins, the issue happens on the next stop command followed by the play for the next image.

Hope this makes sense, let me know if you need more detail.
Comment by Costin Tuculescu [ 02/Jan/17 ]
A little more color...

We have a conference where a presenter is broadcasting audio/video and a file is being played (png). The layout is such that the presenter is up top, taking about 20% of the height of the screen, and the slide is taking about 80% of the bottom area. If there is no one joining the conference while the slide is up, the presenter can "advance" slides without any change in layout, and the slides advance seamlessly. (As John mentioned, we advance by issuing a play command for the next png in the series to queue it up, and then a stop command to stop the previously showing png).

However, when a member joins the conference, there is no disruption to the layout at that time, however when the presenter "advances", the layout flips to a 1x1 video only layout (the slide disappears) and a second later the layout is restored to show the presenter up top and the slide below. We should also note that the members are joining with "recvonly" and are not broadcasting at all.

We need a fix for this layout flip issue as it's very disruptive to the conference. Thank you for your attention to this.
Comment by Anthony Minessale II [ 03/Jan/17 ]
Are you using one of the group:XXX layouts?
If not, which one are you using along with any other conference profile params?
Comment by Costin Tuculescu [ 03/Jan/17 ]
Here are the layouts and the conference profiles.

We have application logic that switches layouts when the conference mode changes (ie from video conference, to slide share, to screen share). But there are no layout changes being requested in this case, and they layout switching on its own.
Comment by Anthony Minessale II [ 03/Jan/17 ]
There is contradictory info:

The desc says:
Begin playing image(s) while other attendees join the meeting and share their webcam

but the comment says:
We should also note that the members are joining with "recvonly" and are not broadcasting at all.

Is there anyone with a webcam at the time of the problem, and what layout are you using at the time of the problem, it says you manually switch layouts. The one in the config you posted says group:grid.
 

Comment by Costin Tuculescu [ 03/Jan/17 ]
You're right, sorry about the contradiction.

Specifically, it's one presenter sharing their cam and slides, and then attendees join "recvonly". When they join, even though they're in no way on the canvas, when we do the next play/stop command, the layout changes. If no one joins in between play/stop commands, the layout doesn't change.
Comment by Mike Jerris [ 03/Jan/17 ]
if layout in config is set to 1x1 does the same thing happen?
Comment by Costin Tuculescu [ 03/Jan/17 ]
Hi Mike, the issue doesn't occur in that case because we can't do a 1x1 layout and share a file at the same time.
Comment by Anthony Minessale II [ 03/Jan/17 ]
on latest master updated with the fix to your png crash and 2 more bugs I found I cannot reproduce this.

I took your exact fileshare-1 layout and switched to it and called in one call with video and started this sequence,

conference 3500 play /root/png1.png;;msleep 10000;;conference 3500 play /root/png2.png;;msleep 3000;;conference 3500 stop current;;msleep 3000;;conference 3500 stop current

During the first 10 sec, I called in another call with no video as a watcher, and I don't observe anything changing.

Comment by Costin Tuculescu [ 03/Jan/17 ]
Are those 2 bugs that were fixed related to this layout issue? We'll try the latest master with all these additional changes and report back.
Comment by Costin Tuculescu [ 03/Jan/17 ]
Anthony, can you try this flow?

conference 3500 vid-layout group:grid-fileshare;;conference 3500 play {png_ms=-1}/root/png1.png;;msleep 10000;;conference 3500 play {png_ms=-1}/root/png2.png;;conference 3500 stop current;;msleep 5000;;conference 3500 stop current;;conference 3500 vid-layout group:grid;;

Try it once without the attendee joining, and then try it again with an attendee joining around 5 seconds before start. Look for the layout reset when the first stop is called.
Comment by Anthony Minessale II [ 04/Jan/17 ]
I do not see any layout changes when I run your command.

I did find that in my changes yesterday I broke the -1 png_ms thing and I fixed it again.
Currently on master I can run what you pasted in the last comment and see no anomaly

I tried:
* one caller in with no video
* one caller with video
* 2 callers, one with video and one without


Comment by Anthony Minessale II [ 04/Jan/17 ]
P.S based on your example you are using layout groups which you originally said no to.
Comment by Costin Tuculescu [ 04/Jan/17 ]
Sorry about the layout group confusion.

We build master this morning and ran our test and are still seeing the issue. Will provide a video to best explain what we're seeing to make sure we're on the same page.
Comment by Costin Tuculescu [ 04/Jan/17 ]
This is not a great recording, but you can see the issue at 0:53 where the layout does some jumping around, where as normally advancing the images is smooth.
Comment by Anthony Minessale II [ 04/Jan/17 ]
Are you saying you can reproduce the issue with:

conference 3500 vid-layout group:grid-fileshare;;conference 3500 play {png_ms=-1}/root/png1.png;;msleep 10000;;conference 3500 play {png_ms=-1}/root/png2.png;;conference 3500 stop current;;msleep 5000;;conference 3500 stop current;;conference 3500 vid-layout group:grid

Did you build it after my comment because it was broken until 11:00am when I pushed the -1 fix back in.
What you may not understand is that playing and stopping files causes the layout to change in group mode because it attaches and detaches from the layers and that is part of the group mechanism and so is callers entering or leaving. What I see when running your exact command you posted is that it executes fast enough that the layout doesn't change, perhaps your server runs slower than mine but I am not seeing the layout change. Either that or you have more params in place or manually set over cli than what you pasted.







Comment by Costin Tuculescu [ 04/Jan/17 ]
The exact command use for testing is:

conference 184174 vid-layout group:grid-fileshare;;conference 184174 play {png_ms=-1}/s3/png/66bde675-95f1-4ec8-b9d5-2d8cfb61764e/ccc517ba-0897-4ce4-94fe-37245a017493/AnyMeeting-1.png;;msleep 10000;;conference 184174 play {png_ms=-1}/s3/png/66bde675-95f1-4ec8-b9d5-2d8cfb61764e/ccc517ba-0897-4ce4-94fe-37245a017493/AnyMeeting-2.png;;conference 184174 stop current;;msleep 5000;;conference 184174 play {png_ms=-1}/s3/png/66bde675-95f1-4ec8-b9d5-2d8cfb61764e/ccc517ba-0897-4ce4-94fe-37245a017493/AnyMeeting-3.png;;conference 184174 stop current;;msleep 5000;;conference 184174 stop current;;conference 184174 vid-layout group:grid

We're storing files in S3 and accessing using a mount. Has no layout issues when there are no users joining/leaving.

We join members to the call using the "originate" command and put them in the dialplan to join the conference.

You mentioned that when callers enter and leave it changes the group mechanism. This sounds like a possible culprit. Does it still do this even if the member is not on the canvas?

Comment by Costin Tuculescu [ 04/Jan/17 ]
I've confirmed that if we set the layout to not use a group, ie fileshare-1, the issue does not occur.
Generated at Sun Jul 23 09:55:27 CDT 2017 using JIRA 7.3.3#73014-sha1:d5be8da522213be2ca9ad7b043c51da6e4cc9754.