Demand Side Traffic Patterns & App Integration Processes

As many community members have observed, the estimated usage reported in the explorer has declined recently. Additionally, many orchestrators have reported a lower average number of concurrent transcoding sessions during the past few weeks. According to the explorer, the estimated usage peaked at 2.4m minutes of transcoding the week of 7/4-7/10, but last week there was only 578k minutes of transcoding! What could explain this drop?

In general, there are a number of reasons why usage can fluctuate not just for Livepeer, but for any video streaming infrastructure provider. One possible reason is that user generated content (UGC) platforms typically are the largest contributors of usage, but these platforms are also way more likely to see peaks in usage as users join the platform and valleys in usage due to user churn (which is typically high for these platforms) when the long tail of users drop off because of lack of engagement with their streams.

Another possible reason that I’d like to highlight in this post and that the team at Livepeer Inc. has observed with the API is the integration process that some developers use when integrating transcoding into an existing production system. I emphasize “existing” because as many developers know updating the backing infrastructure for a production system can be tricky! There is a bit more room to play fast and loose when building a production system from scratch that lacks an existing user base, but I think it makes sense for developers to take extra precautions when integrating new systems in the infrastructure for their existing production system with an existing user base that is regularly using the system.

In the case of Livepeer, the team has observed at least one case where the process for integrating Livepeer involves a thorough testing process to understand the amount of streams that the app could or should send to Livepeer for transcoding. As a result, before a full integration, there may be times when some or all streams are being sent to Livepeer for transcoding and times when no streams are being sent to Livepeer for transcoding. Then, once the necessary testing has been completed, the app would be able to smoothly switch to consistently sending streams to Livepeer without any risk of hurting user experience. The side effect of such an integration process is that there would be more ups and downs in usage. However, the hope is that the ability for developers to take these steps/precautions in the integration process helps them establish the confidence to transition their existing production system to using Livepeer for transcoding over a longer period of time.

This is not to say that this is the reason for all usage fluctuation that has been observed on the network. But, I do think it is worthwhile mentioning this particular reason since it has been observed in practice recently.

1 Like