I am new to WebXR. I was trying to use webRTC with WebXR. The user will first enter into AR session and then create a WebRTC peer connection but ice candidates are not generated in Chrome for Android of the user is in AR session. As soon as the user gets out of AR session, ice candidates are transferred. Is this a bug in Chrome??
The problem is Hardware related. Some devices allow the use of both Front and back camera simultaneously. In such devices, the code worked properly. In other devices, both front and back camera cannot be accessed simultaneously. Hence, code does not work in these devices. Also, the WebXR Device API does not allow access to camera feed at the moment, however it is a proposed feature.
Although I haven't tried it myself. But you can in theory use the canvas captureStream API to stream webXR canvas.
Can you post your code here. You might want to tweak how you pass stream to the webrtc connection.
As far as I know, it is not possible to use canvas.captureStream() because WebXR doesn't render to the canvas directly.
I am also looking for a way to stream a webXR-Session via WebRTC. So I would be highly interested in your solution shivamag00!
Hope to hear from you!
Related
Is it possible to check if camera and microphone are in use by another PC application (like Skype)?
The problem is, I'm able to get the stream object and initiate the connection between two computers, but there's no video nor sound, because the devices are in use by Skype. What I need is a way to detect if the devices are busy in order to tell the user to close the applications that are using the camera and microphone
I know it's possible to check if there are any devices present on the PC with MediaStreamTrack.getSources(), however it does not provide any information about devices status.
The testrtc project has a test that detects silence from a microphone here that could be useful in determining if the audio track returned is silent, and a similar video test that detects frozen or black frames.
There is no direct way, but getUserMedia should throw errors and/or return less audio/video tracks than you would expect if checking whether a device exists.
Devices can be detected either from MediaStreamTrack.getSources or (preferably) the spec-compliant navigator.mediaDevices.enumerateDevices.
I want to extract frames from live video stream using windows phone 8. I'm grabbing my video stream from a device via bluetooth connection. Also I want to do some image processing with the extracted frames. But this process should run on background and should notify user along with defined situations. I searched though the internet with my requirements, but didn't find any solution that could be use to handle that kind of scenario.
So please let me know, is it possible to implement that kind of application using windows phone 8 SDK? If so, please kind enough to provide some details and directives that I should concern. Otherwise please let me know what are the major issues with my scenario.
Thank you very much.
I have successful get the video streaming of local camera by use getUserMedia() in HTML5.But only one camera.I have two cameras,how to get their video streaming at the same time.
Unfortunately this does not appear to be possible, yet. See here and the comments below this article here. Basically the user decides via their browser settings which camera is primary, and no option for secondary, etc, camera exists as of yet.
I'm planning to realize the following project and would be thankful if somebody could verfy my approach!
I want to establish a fully bidirectional wireless realtime communication between a smartphone (cross platform) and a embedded microcontroller running a webserver.
The webserver should provide data of the connected hardware in realtime e.g. temerature.
The smartphone should render these on screen and you should be able to configure the hardware e.g led color with the smartphone and save the config to the embedded webserver.
My first guess was to use HTML5 websockets but they aren't available on all platforms so I got inspired by XBMC, which uses JSON-RPC.
Just imagine a car stero system with bluetooth connected to a µC with webserver and wifi dongle.
My plan is to implement a webapp on the webserver which lets serves the purpose mentioned above. But the tricky part is to get the user to establish a bluetooth connection to the stereosystem because i looked up similar questions which say you can't access stuff like bluetooth on the smartphone with HTML5.
long story short, this is the current idea:
hardware -> µC -> webserver -> HTML5 Webapp-> WIFI -> Smartphone
communication via JSON RCP.
I would be highly thankful if somesone could give a statement to said idea and planned implementation because I never done this before!
Thanks guys!
We at muzzley, have developed a framework to simplify this process. We provide a way for your browser applications to communicate with smartphones. In the side of the smartphone you have widgets that are already done (gamepad, drawpad, switch, swipe, others) or you can build your own html based widget.
(disclaimer: i work for this project)
Most of the work is already done for what you want to do :)
Quick start here:
http://www.muzzley.com/documentation/quick-start.html
You can pull from github several examples here:
https://github.com/muzzley/muzzley-demos/
Lib for browser:
http://www.muzzley.com/documentation/libraries/javascript.html
I hope it helps.
Best
I think your first instinct was probably right. Have you looked at socket.io for node? It's essentially a shiv which ensures that you can use websocket functionality in virtually any combination of device and browser (see list of supported transport mechanisms and browsers here).
It should allow you to avoid bluetooth altogether.
I'm looking for a way to securely deliver video to mobile devices. There are two options:
HLS in tag. This works very nicely for iOS and supports adaptive bitrate, perfect for mobile. However, is seems to only work well on iOS. There seems to be only fragmented support for it on Android. I've read that Android has officially supported it since 3.0, but on all the android devices I've tested (>3.0), HLS hasn't played back on the browser.
Progressive download in tag. This will work on iOS and Android devices fine, but the concern is that since it's just a progressive download of the video, that the user find a way to just grab that video once the browser has finished downloading it. This may be more difficult on iOS, but I'm sure it's not that hard to figure out where the browser stored the video download in a tmp folder somewhere.
Either method I'd say can be protected from deeplinking by using an expiring token approach, where the token is generated serverside with a secret key that only the content server knows about. The video request would only be valid for 5 or 10 minutes, would would kill of deeplinking.
Is anyone aware of any way around these issues? Even if I was able to prevent deeplinking, the user could still get the video itself and re-distribute. Perhaps it's just not possible?
Thanks
Rule #1 of the internet:
If you don't want someone stealing it, don't put it online.
Welcome to the circumvention arms race. Brought to you by DownloadHelper.
There's nothing you can do to stop someone who really wants to pirate your video. There are various measures, like those you mention, that make it more difficult, but someone who really wants to copy it could find a way to capture it from memory, or even just point a camera at the screen and record the playback of the video.
It's the same way you protect your car. You install a steering lock, an alarm and an engine immobiliser, and then someone comes alongs and pulls the car onto a flat-bed truck and drives away with it.
Bottom line - you can't stop a determined thief, but you can make theft more difficult so that you're not the most attractive target.
As I was reading the above I could easily get pass all these techniques pretty quickly.
For a project I can't describe too much because of nda, we created our own protocol based on a well known encryption method can't mention that either , military grade) , encoded packets on the server to the protocol, and decoded on the device.
unfortunately this isn't perfect either because a lot of mobile apps can be re-versed engineered and once you get the key game over, very easy on android, of course you could periodically recycle the key, in which case even if they decompiled the android app and got the key it wouldn't work very long.
This is a lot of work and can't be implemented with html5 or hLS or event rtsp.
It also requires a custom server application that takes the video stream re-transmits it with the custom protocol.
On the other hand the protocol was transport agnostic, which meant we could use a variety of transports, tcp, IAP and bluetooth. Also would work on all mobile / desktop platforms.
The other little requirement, is couldn't use a browser, have to be a custom app.