I am working on webrtc chat app.
system1 : peer1, peer3 | system2 : peer2, peer4
What I did ?
For video call, I am creating one peer1, peer2, and that peer1 very successfully communicate with peer2 (consider video call only).
What I want to do?
I want, peer3 can communicate with new peer4(meanwhile I don't want to disconnect peer1-->peer2).
What happening ?
When I am creating peer3, on that time " navigator.mediaDevices.getUserMedia " getting errors !!!! (I am not using SSL) and new peer3 can't create !.
So, please tell me your suggestions regarding above problem.
It is possible to only peer1 can communicate with other any peer(bidirectional communication)??
This could be the browser failing to capture video from the webcam if it's already in use by another browser or another tab in the same browser. For example, Firefox 57 on my Ubuntu 16.04 machine exhibits this behavior (Chrome does not).
Related
https://chromium.googlesource.com/chromium/src/+/master/docs/early-hints.md suggest this is how one would debug if asset was loaded using early hints (103 HTTP status response) like so:
performance.getEntriesByName('https://a.test/style.css')[0].initiatorType
// => 'early-hints'
https://hg.mozilla.org/try/file/cc6f6c969877f92faf9ebda84653aff9fec62b0b/testing/web-platform/tests/loading/early-hints/resources/preload-initiator-type.html -> would confirm this is true.
Yet when I run this statement in chrome console, i'm getting:
performance.getEntriesByName('https://mywebsite.com/img.jpg')[0].initiatorType
'link'
Did early-hints was replaced with link?
Would assume so, but also am seeing no effect on the waterfall chart when early hints get enabled, so chances are chrome is really not respect 103 and does not preload asset. Any other ideas of how to debug early hints in chrome are more than welcome (Using Chrome 106 on OSX).
I am developing a Chrome extension on windows. It also has a native messaging host. The argument passed to the host named --parent-window is in my case always 0.
According to the Native Messaging Protocol it says
On Windows, the native messaging host is also passed a command line
argument with a handle to the calling chrome native window:
--parent-window=. This lets the native messaging host create native UI windows that are correctly focused.
I open my port for native messaging in the background JS. My understanding is that you cannot use this API in content.
This Chromium Bug appears to be my issue but it was closed as a won't fix.
So when or in what circumstances does Chrome send something useful with the --parent-window?
Further on May 7 the writer who I assume knows a bit about chromium says
Haven't tried it, but could you open your native messaging port in a
content script instead? Sounds like the --parent-window arg might be
useful in that case.
What does he mean and how do I do this?
Answering my own question. In short it does not work as you would expect if you are a windows developer. Possibly comment 2 helps from the "Wont Fix" issue on Chromium.
Comment 2 seems to explain when it might work.
If you are using Native Messaging
(https://developer.chrome.com/extensions/messaging#native-messaging),
it would seem like the --parent-window command line parameter would
provide a solution. Unfortunately, zero is passed for the parent
window if the native messaging connection is made from a background
page and (apparently) the HWND of a transient popup window is passed
if the native messaging connection is made from a browser action
popup. And I am not allowed to call chrome.runtime.connectNative()
from a content script. Therefore, in my extension at least,
--parent-window is not helpful.
My solution is immediately after
port = chrome.runtime.connectNative('myspecial.host.application');
I then use the following;
chrome.tabs.query({ active: true, currentWindow: true }, function (tab) {
console.log(tab[0].title);
port.postMessage({ MessageType: 'chromeTitle', Message: tab[0].title });
});
In your host if you add to this titel " - Google Chrome" then you can call FindWindowEX with the class "Chrome_WidgetWin_1" and the title to get the main handle of Google.
I'm trying to capture audio using WASAPI. My code is largely based on the ChatterBox VoIP sample app. I'm getting audio buffers, but they are all silent (flagged AUDCLNT_BUFFERFLAGS_SILENT).
I'm using Visual Studio Express 2012 for Windows Phone. Running on the emulator.
I had the exact same problem and managed to reproduce it in the ChatterBox sample app if I set Visual Studio to native debugging and at any point stepped through the code.
Also, closing the App without going through the "Stop" procedure and stopping the AudioClient will require you to restart the emulator/device before being able to capture audio data again.
It nearly drove me nuts before I figured out the before mentioned problems but I finally got it working.
So..
1. Be sure to NOT do native debugging
2. Always call IAudioClient->Stop(); before terminating the App.
3. Make sure you pass the correct parameters to IAudioClient->Initialize();
I've included a piece of code that works 100% of the time for me. I've left out error checking for clarity..
LPCWSTR pwstrDefaultCaptureDeviceId =
GetDefaultAudioCaptureId(AudioDeviceRole::Communications);
HRESULT hr = ActivateAudioInterface(pwstrDefaultCaptureDeviceId,
__uuidof(IAudioClient2), (void**)&m_pAudioClient);
hr = m_pAudioClient->GetMixFormat(&m_pwfx);
m_frameSizeInBytes = (m_pwfx->wBitsPerSample / 8) * m_pwfx->nChannels;
hr = m_pAudioClient->Initialize(AUDCLNT_SHAREMODE_SHARED,
AUDCLNT_STREAMFLAGS_NOPERSIST | AUDCLNT_STREAMFLAGS_EVENTCALLBACK,
latency * 10000, 0, m_pwfx, NULL);
hr = m_pAudioClient->SetEventHandle(m_hCaptureEvent);
hr = m_pAudioClient->GetService(__uuidof(IAudioCaptureClient),
(void**)&m_pCaptureClient);
And that's it.. Before calling this code I've started a worker thread that will listen to m_hCaptureEvent and call IAudioCaptureClient->GetBuffer(); whenever the capture event is triggered.
Of course using Microsoft.XNA.Audio.Microphone works fine to, but it's not always an option to reference the XNA framework.. :)
It was a really annoying problem which waste about 2 complete days of mine.My problem was solved by setting AudioClientProperties.eCatagory to AudioCategory_Communications instead of AudioCategory_Other.
After this long try and error period I am not sure that the problem won't repeat in the future because the API doesn't act very stable and every run may return a different result.
Edit:Yeah my guess was true.Restarting the wp emulator makes the buffer silent again.But changing the AudioClientProperties.eCatagory back to AudioCategory_Other again solve it.I still don't know what is wrong with it and what is the final solution.
Again I encounter the same problem and this time commenting (removing) the
properties.eCategory = AudioCategory_Communications;
solve the problem.
I can add my piece of advice for Windows Phone 8.1.
I made the following experiment.
Open capture device. Buffers are not silent.
Open render device with AudioDeviceRole::Communications. Buffers immediately go silent.
Close render device. Buffers are not silent.
Then I opened capture device with AudioDeviceRole::Communications and capture device works fine all the time.
For Windows 10 capture device works all the time, no matter if you open it with AudioDeviceRole::Communications or not.
I've had the same problem. It seems like you can either use only AudioCategory_Other or create an instance of VoipPhoneCall and use only AudioCategory_Communications.
So the solution in my case was to use AudioCategory_Communications and create an outgoing VoipPhoneCall. You should implement the background agents as in Chatterbox VoIP sample app for the VoipCallCoordinator to work .
I am using Netty websockets and everything seems to work fine except this minor issue :
If I close the browser / tab of the js websocket client , the websocket connection is automatcally closed when using Mozilla firefox (currently using firefox 14) but the same thing does not happen in Chrome 20/21.
Anyone seen a similar issue / can anyone tell why is the connection not closed automatically ?
I guess I should have checked this earlier in the chromium bug section but I was not sure if it is a bug.
It has been reported earlier by someone and a chromium bug already exists :
Issue 51687 : WebSocket: Send close with code 1001 on reload / tab close
Update : Someone has submitted a patch to fix this issue, can be seen in the above link.
This may not be right, but I cannot post a comment to your question. Chrome/Chromium does not really close if you have an App running and have selected "Continue running background apps when Chromium is closed" from Settings-->Under the hood.
It may be that it treats the websocket connection as an app. Try looking at your running processes and kill any chrome/chromium process you find.
Again, this is just speculation on my part.
Chrome doesn't close the connection, when a user will close the window or browser.
It will trigger an Error event.
A possible workaround could look like this:
#OnError
public void onErr(Throwable t) {
onClose(this.container.getWsSession(), null);
}
But this will close the connection every time, an Error is triggered. You may wan't to check the throwable, before closing the connection by yourself.
For more discussion, please join this question:
Websocket: Closing browser triggers onError() in chrome but onClose() event in Firefox
I came across this code change in Chromium. It says Chromium now supports both handshake versions, which the code seems to confirm. I mean the second version at Wikipedia (draft-ietf-hybi-thewebsocketprotocol-06).
However, when I connect to my server, the only thing I obtain is the old version, i.e. including these headers:
Sec-WebSocket-Key1: 4 #1 46546xW%0l 1 5
Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
but not the new version which would be a request containing:
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
What am I missing here? I downloaded the latest nightly build and it has been included more than two weeks ago, so that cannot be the cause I guess.
How can I make a WebSocket send the new handshake version?
The code link you posted is for the server-side of the handshake (there is a few places this will likely be used in Chrome such as remote debugging and as a proxy for extensions).
If you really want use the new HyBi-07 protocol version you can try using this branch of web-socket-js that I made. Once Chrome switch to the new protocol, web-socket-js will switch by default also. In order to make web-socket-js work in a browser that already has WebSockets support you will need make some minor tweaks to it to use a different object name instead of WebSocket.
I expect Chrome/WebKit will add the new protocol before long. Note that the API changes to add binary support have only recent been decided so Chrome the new protocol may be added before the API fully supports the new functionality enabled by the protocol.
The only browser I know of that implements the 07 protocol is this build of FF4:
http://www.ducksong.com/misc/websockets-builds/ws-07/