Recording 2018.03.02 22:50:47

Recording 2018.03.02 22:57:32

Thank you.
-Dave

On Fri, Mar 2, 2018 at 11:49 PM, Maxim Solodovnik <[email protected]> wrote:
> Hello David,
>
> could you please provide the complete name of your recording on demo server?
> I'll check raw data, conversion logs and resulting file
>
> On Sat, Mar 3, 2018 at 8:16 AM, David Jentz <[email protected]> wrote:
>> A bit of follow up:
>>
>> Concerned that chromium was the problem, I tried launching it with
>> these two arguments:
>>
>> --use-file-for-fake-video-capture=blabla.y4m 
>> --use-fake-device-for-media-stream
>> found here
>> https://bugs.chromium.org/p/chromium/issues/detail?id=318797
>>
>> While this does seem to solve the issue with chromium requiring a
>> video device /camera (and having the camera with red X otherwise),
>> desktop sharer is still not recording audio.
>> This technique does not solve the problem anyhow, because while it
>> does fake out video, it also fakes out audio..and precludes mic from
>> functioning without camera.
>>
>> Even with the faked audio, still seems as if its not being recorded by
>> my client. Also with the faked audio, vox indicators still working
>> correctly. Not sure the chrome/camera issue was a real issue to begin
>> with.
>>
>> -Dave
>>
>> On Fri, Mar 2, 2018 at 2:24 PM, David Jentz <[email protected]> wrote:
>>> I tested using the same client computer/browser against the
>>> openmeetings demo server and had the same result.
>>>
>>> I guess this is saying its my client software?
>>>
>>> I did notice something new that I hadn't notice before..come to find
>>> out it was also on my local server as well (just did not notice): in
>>> the top right hand corner of the URL bar there is a camera with a red
>>> X in its bottom right corner. This is despite the fact that chromiums
>>> setting for the site already permits access to both camera and
>>> microphone.
>>>
>>> Hover over the camera with red X, it says: Camera blocked This page
>>> has been blocked from accessing your camera
>>> And then gives me 2 option radio buttons, 1 to Always allow <URL>
>>> access to your camera and microphone
>>>                                                               2
>>> continue blocking camera and microphone access
>>> And option 2 is on by default.
>>> Thought I already fixed this via the site settings?
>>>
>>> When I click option 1, and reload the page (openmeetings room), I get
>>> a white box that says microhpone is on (but no image because I have no
>>> camera). For about 1 second the camera icon in the URL bar has no red
>>> X, maybe indicating it is working?
>>> But then after about 1 second the openmeetings inset switches to a
>>> head and sholders with ? on the head, presumably because I have no
>>> camera. At this time the redX on the camera icon in the URL comes back
>>> - appearing like my setting of granting access is not working.
>>>
>>> My new guess is that microphone settings are not working in
>>> openmeetings recordings because there is no camera. It is strange
>>> though, Still getting the microphone is on text, still getting correct
>>> vox indicators, and other users can still hear me. Only thing that
>>> appears to be affected is the recordings, but unfortunately this is
>>> important to us!
>>>
>>> -Dave
>>>
>>> On Thu, Mar 1, 2018 at 10:06 PM, Maxim Solodovnik <[email protected]> 
>>> wrote:
>>>> Is this issue reproducible for you on our demo server
>>>> https://om.alteametasoft.com/openmeetings (latest 4.0.2 release) ?
>>>>
>>>> On Fri, Mar 2, 2018 at 1:04 PM, David Jentz <[email protected]> wrote:
>>>>> Certainly, I will do anything I can do to help debug this.
>>>>>
>>>>> Openmeetings is the recent 4.0.2 release.
>>>>>
>>>>> The server and client are on same OS, red hat 6.9 ( close cousin to centos
>>>>> 6.9)
>>>>> client browser is chromium-browser 64.0.3282.119-1.el6_9.x86_64
>>>>> with
>>>>> chromium-pepper-flash-28.0.0126-1.x86_64
>>>>>
>>>>> java is java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64
>>>>>
>>>>> believe desktop sharer is using
>>>>> icedtea-web-1.6.2-1.el6.x86_64
>>>>>
>>>>> I think I would be able to provide any logs
>>>>> I think I would be able to provide recorded videos/wav files
>>>>> I think providing a login to our openmeetings instance might be 
>>>>> problematic,
>>>>> or remote access to our server (ie ssh/vnc)
>>>>>
>>>>> Again, seems like audio is working just fine in the room (other users can
>>>>> hear, mic VOX indicators working perfectly).
>>>>> Video recorded via desktop sharer working perfectly
>>>>> Just audio in the downloaded mp4 from the desktop sharer recorded video is
>>>>> completely silent..(but audio track appears to be present).
>>>>>
>>>>>
>>>>> -Dave
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 1, 2018 at 8:22 PM Vasiliy Degtyarev <[email protected]> wrote:
>>>>>>
>>>>>> Hello, Dave!
>>>>>>
>>>>>> I have checked recording on demo server, audio works as expected.
>>>>>> Please explain more details: sharing PC OS, browser, java version.
>>>>>>
>>>>>> Thanks,
>>>>>> Vasiliy
>>>>>>
>>>>>> 01.03.2018 8:08, David Jentz пишет:
>>>>>> > Testing in openmeetings 4.0.2 on linux (centos 6.9) server
>>>>>> >
>>>>>> > Desktop sharer appears to make a mp4 just fine. Video playback is 100%
>>>>>> > fine. Mp4 has audio embedded (playback in VLC indicates 200 blocks
>>>>>> > decoded, 200 buffers played 0 buffers lost).
>>>>>> >
>>>>>> > The sound being spoken into the microphone is not being recorded,
>>>>>> > however. Instead the audio track appears to be completely silent.
>>>>>> >
>>>>>> > Microphone in openmeetings appears to work OK. Other users in the same
>>>>>> > openmeetings room can hear just fine.
>>>>>> >
>>>>>> > Circle audio indicator in the openmeetings room user list appears to
>>>>>> > be flashing when words spoken - even recorded in video created by
>>>>>> > desktop sharer. All good.
>>>>>> >
>>>>>> > Volume level bar in the users camera inset are also correctly
>>>>>> > indicated when words spoken into microphone. This is also recorded in
>>>>>> > the mp4 created by desktop sharer.
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > Think this may have been an issue for us in 4.0.1 also.
>>>>>> >
>>>>>> > This was last known to work in 3.2.1
>>>>>> > Found some files in the webapps/openmeetings/stream directories with
>>>>>> > matching timestamps to the recordings.
>>>>>> >
>>>>>> > The flv files played back with 0 audio buffers in vlc
>>>>>> > The .wav file played back with 558 blocks, 558 buffers played, 0
>>>>>> > buffers dropped, but also completely silent.
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > -Dave
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>
>
>
> --
> WBR
> Maxim aka solomax

Reply via email to