Squashing the Bugs: 6 Steps for Solving Video Streaming Problems
The quintessential tech support parody usually starts (or ends) with the question, “Is it plugged in?” While that simple step is often mocked, the question begins an investigative process to figure out what factors are causing the problem one is experiencing. In my work as a video solutions architect, my clients come to me with a wide range of problems. My first role in these engagements is to make sure everyone’s on the same page. I need to rewind the client’s memory back to that “Is it plugged in?” step, as I’m usually not the original architect of his or her technology process.
As I start the discovery process of any troubleshooting engagement, I aim to have clear communication with the client to get to a solution as quickly, efficiently, and affordably as possible. Here are my general guidelines:
Outline the technology stack: Ask for any documentation that shows each moving part in the system. If that doesn’t exist, create it. With a live-streaming solution, for example, I would want to know what servers (or services) are being deployed, where they are being deployed, what player technologies are in use, and so on.
Define roles: What resources does the client already have on the project? Does the client identify the personnel on his or her end as stakeholders, product owners, and development/design/quality assurance resources? Who has actively been trying to solve the problem already, and what was already done to try to find or remedy the problem? How familiar is each person on the team with the problem? What role(s) is the client expecting me to fulfill? Will I be finding and fixing the problem, or will other people execute tasks under my guidance?
Look for obvious answer(s) first: The longer I do my job, the more likely I’ve seen the same issue with other engagements and projects. Most problems have more apparent symptoms and causes (e.g., playback buffering caused by too high a bitrate and too low a connection speed). Obvious answers can also just be “fact of life” answers too—there might be a known problem with the technology in use, and the client is just not aware. For example, WebRTC support can vary widely from one browser to the next, and audio not playing in a live stream may just be the lack of a codec available on a particular browser or system.
Replicate the problem (or not): After potential suspects have been lined up, isolate the issue by reproducing the problem consistently across different environments. If the problem is believed to be with a player technology, does the same problem occur with other player technologies?
Propose solutions: Devise a workaround to fix the immediate problem(s) at hand. If there’s a systemic issue that requires a major overhaul to an existing process, identify which resources will be needed, and provide estimates around timeline and budget. If there’s more than one potential path forward, explore each with respect to resources, timeline, and budget.
Redefine roles: Oftentimes, there needs to be new roles devised and assigned in the team to make sure the project stays the course to completion. Too many times, I’ve encountered clients who couldn’t identify a product owner, someone responsible for steering product development. If there’s not a dedicated project manager, assign one or hire one. After proposed solutions have been made, there should be a clear path forward with respect to who’s doing what and how much time per week each resource will be available and/or assigned to the project.
Of course, there can be much more to defining a problem and paving a path forward than I’ve discussed here, but make sure you don’t skip past or underestimate the effort and time required to complete a thorough discovery—there just might be an overlooked unplugged item at play.
[This article appears in the October 2019 issue of Streaming Media Magazine as "Discovery: Defining a Problem."]
When will the industry jettison HTTP-segment-based streaming and buffer-based playback, both of which hold us back? How about right now, our columnist proposes.
Sure, today's OTT video platforms could share data and create comprehensive video recommendation systems, but they don't want to. Here's why they should care.
As people go online for more of their daily video, they have higher expectations than ever. Rebuffering is the top annoyance for many.
Slow start times and rebuffering delays are still with us, and these problems cost publishers billions of hour of viewing time in 2017.