Below are the expectations from WebRTC
Streaming of audio, video or other data.
Getting network information such as IP addresses and ports. Exchanging of this information with other WebRTC clients (peers) to enable connection even through NATs and firewalls.
In case of error reporting, initiation, session closing and coordinating with signaling communication.
Communicating with streaming video, audio or data.
Exchange of information about media and client capability such as resolution and codecs.
The above functions are been implemented by WebRTC by employing some main APIs listed below:
MediaStream (aka getUserMedia)
RTCPeerConnection
RTCDataChannel
Below is a close look at these APIS
MediaStream
getUserMedia or MediaStream takes the access to data streams for example from user’s camera and microphone. MediaStream is available in Chrome, Firefox and Opera. MediaSream API represents synchronized streams of media. This can be well-explained that a stream taken from camera and microphone input has synchronized video and audio tracks. Each MediaStream has an input, which might be a MediaStrem generated by navigator. getUserMedia(), and an output might have been passed to a video element or an RTCPeer Connection.
getUserMedia() method takes three parameters:
A constraint’s object.
Success callback which, if called, is passed a MediaStream.
Failure callback which, if called, is passed an error object.
Each MediaStream has a label, such as ’Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ’. An array of MediaStreamTracks is returned by the getAudioTracks() and getVideoTracks() methods.
For the simpl.info/gum example, stream.getAudioTracks() returns an empty array (because there’s no audio) and, assuming a working webcam is connected, stream.getVideoTracks() returns an array of one MediaStreamTrack representing the stream from the webcam. Each MediaStreamTrack has a kind (‘video’ or ‘audio’), and a label (like ‘FaceTime HD Camera (Built-in)’), and represents one or more channels of either audio or video. In this case, there is only one video track and no audio, but you can easily imagine with use cases where there are more: for example, a chat application that gets streams from the front camera, rear camera, microphone, and a ‘screenshared’ application.
getUserMedia can also be added in Chromium-based apps and extensions. Adding audioCapture and/or videoCapture permissions enables permission to be requested and granted only once, on installation. Thereafter, the user permission for camera or microphone access is not asked.
Similarly, pages using HTTPS: permission only has to be granted once for getUserMedia(). Very first time an Always Allow button is displayed in the info-bar of the browser.
It is always required on enabling MediaStream for any streaming data source not just a camera or microphone. This enables streaming from disc or from arbitrary data sources such as other inputs and sensors.
Note that getUserMedia() must be used on a server, not the local file system, otherwise a PERMISSION_DENIED: 1 error will be thrown.
2. RTCPeerConnection
RTCPeerConnection: Audio or video calling holds the extension of encryption and bandwidth management. It gets supported in Chrome (in desktop and Android both), Opera (on desktop and Android) and of course in Firefox too. RTCPeerConnection is implemented by Chrome and Opera as webkitRTCPeerConnection and by Firefox as mozRTCPeerConnection. There’s an ultra-simple demo of Chromium’s RTCPeerConnection implementation at simpl.info/pc and a great video chat application at apprtc.appspot.com. This app uses adapter.js, a JavaScript shim maintained by Google, that abstracts away browser differences and spec changes.
RTCPeerConnection is the WebRTC component that handles stable and efficient communication of streaming data between peers.
RTCPeerConnection safeguards web developers from the myriad complexities. The codecs and protocols used by WebRTC takes care of huge amount of work to make real-time communication even over unreliable networks:
Packet loss concealment
Echo cancellation
Bandwidth adaptivity
Dynamic jitter buffering
Automatic gain control
Noise reduction and suppression
Image ‘cleaning.’
WebRTC Signalling, session control, network and media information
WebRTC uses RTCPeerConnection to communicate streaming data between browsers. Along with this it also needs a mechanism to coordinate communication and to send control messages. This process can be defined as a signaling. One should know that signaling is not part of the RTCPeerConnection API.
developers can choose whatever messaging protocol they prefer, such as SIP or XMPP, and also an appropriate duplex (two-way) communication channel.
WebRTC needs four types of server-side functionality:
User discovery and communication.
Signaling.
NAT/firewall traversal.
Relay servers in case peer-to-peer communication fails.
RTCDataChannel: peer-to-peer communication of generic data. The API is supported by Chrome 25, Opera 18 and Firefox 22 and above.
References
https://dzone.com/articles/how-to-create-your-first-webrtc-application
Streaming of audio, video or other data.
Getting network information such as IP addresses and ports. Exchanging of this information with other WebRTC clients (peers) to enable connection even through NATs and firewalls.
In case of error reporting, initiation, session closing and coordinating with signaling communication.
Communicating with streaming video, audio or data.
Exchange of information about media and client capability such as resolution and codecs.
The above functions are been implemented by WebRTC by employing some main APIs listed below:
MediaStream (aka getUserMedia)
RTCPeerConnection
RTCDataChannel
Below is a close look at these APIS
MediaStream
getUserMedia or MediaStream takes the access to data streams for example from user’s camera and microphone. MediaStream is available in Chrome, Firefox and Opera. MediaSream API represents synchronized streams of media. This can be well-explained that a stream taken from camera and microphone input has synchronized video and audio tracks. Each MediaStream has an input, which might be a MediaStrem generated by navigator. getUserMedia(), and an output might have been passed to a video element or an RTCPeer Connection.
getUserMedia() method takes three parameters:
A constraint’s object.
Success callback which, if called, is passed a MediaStream.
Failure callback which, if called, is passed an error object.
Each MediaStream has a label, such as ’Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ’. An array of MediaStreamTracks is returned by the getAudioTracks() and getVideoTracks() methods.
For the simpl.info/gum example, stream.getAudioTracks() returns an empty array (because there’s no audio) and, assuming a working webcam is connected, stream.getVideoTracks() returns an array of one MediaStreamTrack representing the stream from the webcam. Each MediaStreamTrack has a kind (‘video’ or ‘audio’), and a label (like ‘FaceTime HD Camera (Built-in)’), and represents one or more channels of either audio or video. In this case, there is only one video track and no audio, but you can easily imagine with use cases where there are more: for example, a chat application that gets streams from the front camera, rear camera, microphone, and a ‘screenshared’ application.
getUserMedia can also be added in Chromium-based apps and extensions. Adding audioCapture and/or videoCapture permissions enables permission to be requested and granted only once, on installation. Thereafter, the user permission for camera or microphone access is not asked.
Similarly, pages using HTTPS: permission only has to be granted once for getUserMedia(). Very first time an Always Allow button is displayed in the info-bar of the browser.
It is always required on enabling MediaStream for any streaming data source not just a camera or microphone. This enables streaming from disc or from arbitrary data sources such as other inputs and sensors.
Note that getUserMedia() must be used on a server, not the local file system, otherwise a PERMISSION_DENIED: 1 error will be thrown.
2. RTCPeerConnection
RTCPeerConnection: Audio or video calling holds the extension of encryption and bandwidth management. It gets supported in Chrome (in desktop and Android both), Opera (on desktop and Android) and of course in Firefox too. RTCPeerConnection is implemented by Chrome and Opera as webkitRTCPeerConnection and by Firefox as mozRTCPeerConnection. There’s an ultra-simple demo of Chromium’s RTCPeerConnection implementation at simpl.info/pc and a great video chat application at apprtc.appspot.com. This app uses adapter.js, a JavaScript shim maintained by Google, that abstracts away browser differences and spec changes.
RTCPeerConnection is the WebRTC component that handles stable and efficient communication of streaming data between peers.
RTCPeerConnection safeguards web developers from the myriad complexities. The codecs and protocols used by WebRTC takes care of huge amount of work to make real-time communication even over unreliable networks:
Packet loss concealment
Echo cancellation
Bandwidth adaptivity
Dynamic jitter buffering
Automatic gain control
Noise reduction and suppression
Image ‘cleaning.’
WebRTC Signalling, session control, network and media information
WebRTC uses RTCPeerConnection to communicate streaming data between browsers. Along with this it also needs a mechanism to coordinate communication and to send control messages. This process can be defined as a signaling. One should know that signaling is not part of the RTCPeerConnection API.
developers can choose whatever messaging protocol they prefer, such as SIP or XMPP, and also an appropriate duplex (two-way) communication channel.
WebRTC needs four types of server-side functionality:
User discovery and communication.
Signaling.
NAT/firewall traversal.
Relay servers in case peer-to-peer communication fails.
RTCDataChannel: peer-to-peer communication of generic data. The API is supported by Chrome 25, Opera 18 and Firefox 22 and above.
References
https://dzone.com/articles/how-to-create-your-first-webrtc-application
No comments:
Post a Comment