Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.1.0 Apache Release
-
Fix Version/s: 3.1.0
-
Component/s: None
-
Labels:None
Description
The problem is that the attachCamera method is invoked multiple times when the video device settings initialize:
1) As soon as the two combobox'es rendered completely each will call "attachCamera" and re-attach the video to the view (2 calls)
2) as soon as the user clicks "Allow" in the flash settings, the attachCamera function is invoked again (what for ?) (1 call)
Somehow this leads to a bug in the application that creates two videos and one is no more resizable.
Also the video view that the attachCamera method is using is the wrong videoview.
There are two preview video objects in the device settings:
a) One for the actual current webcam view (aka "_publisher")
b) One for the playback of the 5 second self recording test video (aka "_viewer")
The attachCamera function attaches the stream to the _viewer instead of the _publisher.
There is also a 3th problem (that is also present when having no "attachCamera" function enabled, but simply doing a 5 second recording test). But the auto-attaching of the Camera to the videoview makes it more obvious:
When you click "no Audo/Video" as device settings, your webcam still shows the "red status light" as if some application access it. Actually this should not happen. The status light should turn off when you don't use your webcam. The issue is that the cam is somehow not correctly unattached from the videoview.
The issues of the 3th problem is in the "_stop" method in the "baseVideoStream.lzx"
_stop will only be execute a "clear" (that will un-attach the Camera from the videoview)
if (_ns != null) //if there is a netstream attached to the video
=> In the device settings _ns is null, cause you just want to show a preview
The effect is that _stop will never call "clear"
By adding a manual "clear" to the attachCamera function (and when the window closes), the camera status light goes off when you choose "no Audio/Video" as setting and click on "start conference".
I will try to bundle a patch for those issues now.
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
URL: http://svn.apache.org/r1457361
Log:
Improves OPENMEETINGS-570, but does not fixes all use cases.
Some issue remain:
a) you still can provoke the status light to stay on
- The status light of the cam does now switch off if you choose "no Audio/video" directly after entering the room.
But you still can provoke it to stay on when it actually should go off, by doing the following: - If you choose some valid device settings,
- click on start conference
- click on "Re-Sync" and choose "No Audio/video"
- click on start conference
=> Result should be: The cam's status light should go off as you don't share anything. But the status light stays on in the camera device.
b) The attachCamera might be still called duplicate.
The resolutions are loaded via a datapath. The datapath initilizes not synchronized with the camera combobox. The nature of this datapath/xPath construct is that you can't say for sure when it will initialize and espacially when init is complete.
It should be reworked so that the resolution combobox items are initialized in the method "initItemsAndDefaultAttachCamera" so that we can be 100% sure that the attachCamera is not accidently called before the camera combobox is filled with items/initialized.
Greatly improved, cheers!
I can confirm point a you mention.
One suggestion I would still make to improve the intuitiveness of the UI:
The preview box shows the webcam feed as it will be in the conference. This gives immediate visual feedback, showing if the right settings have been chosen.
This means that when the user selects "Audio only" or "No audio/video", the video feed should not be shown. One could replace it with either the background color, or with the default avatar picture, or with the user's avatar. Any of those would work.
Fixed in 3.1.0
If "unattach" is not executed, the effect is that the Flash Player never releases the cam again.
Practically that means:
Often cameras have this red light or some other indicator that the camera is accessed by something.
Because the "un-attach" is missing in our code, the camera is never released again. The same problem exists if the attachCamera function is commented out but you do a 5-sec recording test in the device settings.
I did try out some reset methods but actually it never worked.
However it works for the usual videoPods. For example if you have configured the auto-close option in the device settings with some valid settings, enter and exit the room, you can see that your status light in the camera gets on and off when you leave the room.
But as soon as "attachCamera" is executed, those resources are never released, you can only reload your browser to get rid of the status lights.