What is video-io?

I worked on a project to create a generic web component named video-io for publish-subscribe in WebRTC. With the growing number of WebRTC enabled video call and conferencing services, we continue to see a trend of vendor lock-ins. The end result is that only a few popular apps dictate the experience of a vast majority of the users. My project is an attempt to separate the service specific part from the client app logic. It allows web developers to create such communication apps independent of any specific service, and to easily connect it to a wide range of media servers or hosted services. 

Introducing Ezcall

My project, Ezcall, demonstrates a lightweight call signaling and peer-to-peer control of WebRTC video conferencing.  

Two main goals of this project are: (1) to show a lightweight call signaling using push notifications, as well as serverless call signaling using email messaging, and (2) to do peer-to-peer control of video conferencing application logic, using WebRTC API in the browser.

How to easily customize your virtual camera?

Checkout this demonstration video of a virtual camera using RTC Helper.

The sub-project "RTC Camera and Screen" is user friendly, and allows you to easily customize camera and screen share behavior on web video conferencing apps that use WebRTC's getUserMedia and getDisplayMedia APIs.

Introducing RTC Helper

What?

RTC Helper is a simple and easy-to-use software that can intercept WebRTC (web real-time communication) and related APIs in the browser, and change the behavior of web apps in real-time. It allows you to analyze, customize and improve audio/video communication on third-party websites as well as your own web apps.

Two main goals of this project are: (1) to allow end-user customization of WebRTC experience, without depending on the features provided or supported by the third-party websites, and (2) to allow developers to rapidly create proof-of-concept (PoC) of innovative ideas and emerging features built on top of WebRTC.

A deep dive into WebRTC topology

There are many prior articles on the web about the WebRTC media path topology in a multiparty scenario. Those usually cover the basic topology of full-mesh and centralized, including MCU and SFU. 

In practice, conferencing systems often exhibit complex topologies beyond this basic view. For example cascaded servers can scale to a much larger meeting or live streaming, especially when participants are geographically distributed and clustered. Separate topology for audio vs. video media paths may enable easy integration and interoperation with telephone and VoIP systems.

In this article [Open as PDF], I take a deep dive into WebRTC media path topology — understanding the benefits and tradeoffs of various alternatives — including, but also beyond, the simplified view of full mesh, MCU and SFU.

How not to design a video conferencing product?

"Can you please stop sharing your screen so that I can share mine?" "I can't see that part of your shared screen because those buttons are overlaid on top." "How can I share my second webcam without stopping the first?" "Can you please say that again? I missed the last part." "It shows only up to nine videos even though I have a very big screen."

Do you ever feel frustrated due to some artificial restriction imposed by the video conferencing product you use? In this informal article, which some will find quite opinionated, I list some annoying product "features" when it comes to video conferencing. 

What do I do as a software architect?

"I am the Architect. I created the matrix. I’ve been waiting for you." -- The Architect

I present my view on what an architect does or should do? And what are the important things to keep in mind in my opinion? 

Topics: Introduction. Making decisions using trade-offs. Research and evaluate technology and tools. Create proof-of-concept of big picture. Systematically divide the goal into smaller solvable problems. Create knowledge base and training for others. Continuous monitoring and improvement of the system. Identify and address disruptive technologies. Conclusions.

From "TO DO" to "DONE"

What does it take to get things done? Why do some tasks get done quickly while others drag on forever? Is there a science behind it? Or just philosophy?

Here, I present my thoughts on these topics. This is largely based on my first hand experience in software industry as well as academia, working in small and large companies, collaborating in small and large teams, and observing wide range of things getting or not getting done. 

Named stream abstraction for WebRTC notification with P2P media

This is a continuation of my earlier article on WebRTC notification system and signaling paradigms which presents, among others, a named stream abstraction for WebRTC signaling. That article also mentioned my light weight notification server notify.py and sample client code webrtc.html as part of my open source rtclite project. 

In this article I present another light weight notification server streams.py and sample client code streams.html as part of that project. This enables named stream abstraction described in my earlier article. The named stream abstraction is closer to the traditional Flash Player's NetStream based publish-subscribe media, and facilitates wide range of application use cases.

Multi-language software programs

When two bilingual people talk to each other, they often tend to mix the two languages in their conversation. Have you heard of Hinglish?

As a software developer, it makes me wonder - is this doable or already done for programming languages?

Vanilla JS

I am a proponent of using Vanilla JS [1,2,3,4] wherever possible. It is plain JavaScript without external frameworks. In my last two jobs, I built many feature-rich and cross platform apps using HTML5, JavaScript and CSS, without depending on the popular frameworks such as jQuery, React or Angular. There are numerous articles on the web about the benefits (and problems) of using plain JS, i.e., without frameworks. Here, I present my thoughts and some reading list for developers who want to avoid frameworks too if possible.

A generic video-io component for WebRTC

This article proposes a generic video-io web component for WebRTC. It can enable various real-time applications such as voice/video conferencing, video messaging, video presence and video broadcast. This client side component may be connected with any signaling channel or mechanism to integrate with existing or new websites or applications. 

By encapsulating the core functions in a single easy-to-understand component, the component enables reuse of the core media features present in WebRTC. Without this, a user relies on the individual website or application developer to support and expose those media features. 

Additionally, I describe the design of a global secure application service that can act as a signaling mechanism for all such component instances.

Lessons in web software development

Here is a summary of what I feel are important to me for creating web applications as an individual developer or in a small team. My hope is to help other developers with the important topics that I assembled. These topics include local development, cross platform and responsive, loose coupling but strict APIs, flexible code, customization, avoid artificial and arbitrary restrictions, state vs. stateless, separation of data and application logic, performance, robustness, caching, one more level of indirection, security, configuration, and reduce fat!

WebRTC notification system and signaling paradigms

This article describes notification system in WebRTC, and presents some common signaling paradigms found in existing WebRTC applications: How does WebRTC work? What is a notification service? What are the signaling paradigms? Which one would you choose? Can the abstractions be converted from one another?

Reason for technology failures - chat bots, video conferencing, or you name it.

Every so often, I come across articles explaining why a piece of technology failed. For example, why chat bots failed in 2018, or why video call did not work for customer support. I think the answer to these and other similar questions can be attributed to three points: (1) not a holistic approach, (2) wrong audience, (3) unreasonable expectations. Let me elaborate further.