I'm building an application with peer-to-peer video calling. So far, I only know WebRTC. Is this sufficient for p2p video calling across the globe if I just have simplest Turn server(s)? By sufficient I mean it is as smooth as a normal video calling services like Google Meet or Zoom. If no, what else should I do to ensure smooth video calling?
For P2P calls with a few participants, WebRTC should absolutely be sufficient. WebRTC has evolved so much in the past decade that it's not unreasonable to estimate that most video applications that are not Zoom are built on it.
There are lots of tutorials about building WebRTC apps from scratch (here's one on DEV, and I appreciate everything Karl Stolley writes).
The only question is if you need to build the WebRTC logic from scratch. Jitsi is a good open-source library. There are other solutions with free tiers like Twilio, Agora, or Daily (full disclosure, where I work).
Good luck!
Related
I just bought a Sony A7 and I am blown away with the incredible pictures it takes, but now I would like to interact and automate the use of this camera using the Sony Remote Camera API. I consider myself a maker and would like to do some fun stuff: add a laser trigger with Arduino, do some computer controlled light painting, and some long-term (on the order of weeks) time-lapse photography. One reason I purchased this Sony camera over other models from famous brands such as Canon, Nikon, or Samsung is because of the ingenious Sony Remote Camera API. However, after reading through the API reference it seems that many of the features cannot be accessed. Is this true? Does anyone know a work around?
Specifically, I am interested in changing a lot of the manual settings that you can change through the menu system on the camera such as ISO, shutter speed, and aperture. I am also interested in taking HDR images in a time-lapse manner and it would be nice to change this setting through the API as well. If anyone knows, why wasn't the API opened up to the whole menu system in the first place?
Finally, if any employee of Sony is reading this I would like to make this plea: PLEASE PLEASE PLEASE keep supporting the Remote Camera API and improve upon an already amazing idea! I think the more control you offer to makers and developers the more popular your cameras will become. I think you could create a cult following if you can manage to capture the imagination of makers across the world and get just one cool project to go viral on the internet. Using http and POST commands is super awesome, because it is OS agnostic and makes communication a breeze. Did I mention that is awesome?! Sony's cameras will nicely integrate themselves into the internet of things.
I think the Remote Camera API strategy is better than the strategies of Sony's competitors. Nikon and Canon have nothing comparable. The closest thing is Samsung gluing Android onto the Galaxy NX, but that is a completely unnecessary cost since most people already own a smart phone; all that needs to exist is a link that allows the camera to talk to the phone, like the Sony API. Sony gets it. Please don't abandon this direction you are taking or the Remote Camera API, because I love where it is heading.
Thanks!
New API features for the Lens Style Cameras DSC-QX100 and DSC-QX10 will be expanded during the spring of 2014. The shutter speed functionality, white balance, ISO settings and more will be included! Check out the official announcement here: https://developer.sony.com/2014/02/24/new-cameras-now-support-camera-remote-api-beta-new-api-features-coming-this-spring-to-selected-cameras/
Thanks a lot for your valuable feedback. Great to hear, that the APIs are used and we are looking forward nice implementations!
Peter
The Glass Mirror Timeline API document suggests that video can be streamed to a Glass headset (https://developers.google.com/glass/timeline). I'm trying to determine whether this could theoretically work with a WebRTC connection? Documentation is limited around the browser/rendering capabilities of the timeline so has anyone tried something similar?
Ran across a discussion about WebRTC + Glass in a reported issue - https://code.google.com/p/webrtc/issues/detail?id=2083
From the sound of things someone got it to work in chrome beta at 176*144. There were some audio/frame rate issues that appear to have been resolved. Note though they talk about streaming video/audio from the glass to another machine not video streaming into the glass display. I believe that at this point it will only work in chrome beta & doubt you could integrate this into the timeline smoothly, though with how hard Google is pushing WebRTC I would not be surprised to see increased support. I'll be testing this out with my own WebRTC demos soon & will know more.
WebRTC for Google glass has been reported: http://www.ericsson.com/research-blog/context-aware-communication/field-service-support-google-glass-webrtc/. There were some limitations, e.g. the device overheated after 10 minutes.
Another case - http://tech.pristine.io/pristine-presents-at-the-austin-gdg (thanks to Arin Sime)
I want to embed a video stream into my web page, which is part of our own cloud based software. The video should be low-latency (like video conferencing), and it would be preferable, but not required, for it to include audio. I am comfortable serving streaming binary data from the server-side, and embedding it into the page using HTML5 video.
What I am not comfortable with is the ability to capture the video data to begin with. The client does not already have a solution in place, and is looking to us for assistance. The video would be routed through our server equipment, and not be an embedded peice that connects directly to the video source.
It is a known quantity for us to use a USB or built-in camera from the computer. What I would like more information is about stand-alone cameras.
Some models of cameras have their own API documentation (example). It would seem from what I am reading that a manufacturer would typically have their own API which they repeat on many or all of their models, and that each manufacturer would be different in their API. However, I have only done surface reading and hope to gain more knowledge from someone who has already researched this, or perhaps even had first hand experience.
Do stand-alone cameras generally include an API? (Wouldn't this is a common requirement, so that security software can use multiple lines of cameras?) Or if not an API, how is the data retrieved from the on-board webserver? Is it usually flash based? Perhaps there is a re-useable video stream I could capture from there? Or is the stream formatting usually diverse?
What would I run into when trying to get the server-side to capture that data?
How does latency on a stand-alone device compare with a USB camera solution?
Do you have tips on picking out a stand-alone camera that would be a good fit for streaming through a server?
I am experienced at using JavaScript (both HTML5 and Node.JS), Perl and Java.
Each camera manufacturer has their own take on this from the point of access points; generally you should be able to ask for a snapshot or a MJPEG stream, but it can vary. Take a look at this entry on CodeProject; it tackles two common methodologies. Here's another one targeted at Foscam specifically.
Get a good NAS, I suggest Synology, check out their long list of supported IP Web Cams. You can connect them with a hub or with a router or whatever you wish. It's not a "computer" as-in "tower", but it does many computer jobs, and it can stay on while your computer is off or away, and do thing like like video feeds, torrents, backups, etc.
I'm not an expert on all the features, so I don't know how to get it to broadcast without recording, but even if it does then at least it's separate. Synology is a popular brand and there are lot of authorized and un-authorized plugins for it. Check them out and see if one suits you.
In a nutshell Fast Dormancy allows the RRC state machine to go to IDLE(CELL_PCH) from CELL_DCH without waiting for the timer to expire. Is there any OS (Android, Windows Phone, iOS etc) which exposes APIs using which we can invoke fast dormancy on 3G devices? Any pointers appreciated.
EDIT: Does any OS expose API's to
switch off 3G radio or switch radio
states(DCH,FACH,IDLE etc.)
I'm not sure if I understood your question correctly (I'm not familiar with the actual 3G-technology), but at least BlackBerry API (since 4.2.1) does have the following method:
Requests that the radios belonging to
the provided Wireless Access Families
be powered off.
http://www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/system/Radio.html#deactivateWAFs(int)
Constants used with the above:
http://www.blackberry.com/developers/docs/6.0.0api/net/rim/device/api/system/RadioInfo.html#WAF_3GPP
Not sure if this is what you actually meant.
It seems that Blackberry also expose fast dormancy since API 4.0.0
http://www.blackberry.com/developers/docs/5.0.0api/net/rim/device/api/io/IOProperties.html#CDMA_SET_FAST_DORMANCY_FLAG
and
http://www.blackberry.com/developers/docs/4.0.2api/net/rim/device/api/io/IOProperties.html
The OFono stack used by MeeGo seems to have Fast Dormancy settings (and radio toggling) in the radio settings api, but I can't really see at which level those would be available to users. The API doc is in their git repo:
http://meego.gitorious.org/meego-cellular/ofono/blobs/5639c653979e324e0b3a195ec3fab07fc2bd3a05/doc/radio-settings-api.txt
I've read NCFD has been blamed for spotty 3G performance on iOS devices in some cases, so I'm not sure programmatically playing with at an application level is such a good idea, especially since you'd be making assumptions about the entire platform's network stack requirements.
Just got my iPad yesterday and I wanna start programming a distributed game between iPads for a little community across the globe, so no blue-tooth.
I've heard of the XMPP protocol to enable data exchange between two PCs, such like this thread on SO
Basically, the approach is a decentralized solution, once a valid connection is established between two iPads, there is no need for the server to be involved. The two iPad can communicate using XMPP. I know the majority of the data would be textual, although some images are also to be transferred across the net.
My concern at the moment is just proof of concept. Is this a good approach? How to re-connect if the connection is broken due to poor Wi-Fi signal strength? Is there a better way to do this sort of thing?
I am new to iPad game programming so any suggestion is welcomed and appreciated.
You should use GameKit for this. It's way easier and doesn't need accounts. Also all the device finding stuff is already implemented. (Apple proprietary format, iOS only)