The Livepeer protocol explorer shows a series of charts and statistics about the usage of Livepeer protocol, including an estimate of how many minutes of unique video are transcoded by the network each week. The methodology for estimating this number is undergoing an update shortly, and this post will provide some background on the statistic, and the old vs new methodology.
Background on Fees vs Estimated Minutes Usage
While most of the stats shown in the explorer is observable directly via on chain data, one such metric, “Estimated Usage”, is not. The only data that the blockchain and protocol are aware of in terms of usage is the amount of ETH fees that are redeemed by node operators in exchange for performing video transcoding work. This is captured by the on-chain observable, “Fees Paid” chart, which converts the ETH based fees to USD representation for more consistent comparison.
However, while the fees earned do a great job of capturing demand for the network, it is hard for someone to tie this to some semblance of what is actually going on in terms of video transcoding - the core capability of the network. It’s far easier for someone to understand how Livepeer is being used when they hear that the network grew its minutes transcoded/week from 1.5M to 2M (an additional 8000+ hours of unique input video), than it is to draw that conclusion from a fee jump from 6K to 8K for example.
So as a convenience, the builders of this particular explorer, do their best to estimate the number of minutes transcoded through the network, from a variety of sources. As the methodology for creating this estimate was falling a bit out of date with the observed patterns of network usage, the explorer team has updated the methodology.
Old Methodology
The old methodology used a combination of fee-derived minutes, along with estimated pixel counts with a live stream ABR ladder, Livepeer Studio usage, and incorporated some redundancy or backup transcoding due to the quality levels on the network required for reliable live streams.
This has fallen slightly out of date because of a number of factors:
- Introduction of VOD transcoding capabilities and growing usage through Studio.
- Additional Broadcaster nodes on the network with different usage patterns.
- Less required redundancy due to the high quality performance of the node operators.
- Varying price points and bitrate ladders for different features.
New Methodology
The latest methodology, which will be deployed soon, will take these factors into account. Instead of making flat assumptions about the bitrates, which were livestream dominated, it will take a heuristic from observed Livepeer Studio usage, and apply this generally to the usage on the network across B’s.
Minutes estimated may go down because of reduced redundant transcoding for backups, but they may increase because of the incorporation of VOD transcoding and the lower price point for these jobs.
It is important to note that these estimates are a moving target, and it becomes harder and harder (or impossible) to make reliable estimates as the diversity of Broadcast nodes and job types increase. As they all pay different prices, request different variations of VOD/Livestreaming or other forms of less conventional transcoding, none of which are observable via onchain data, the estimates get further off. Those looking to gauge the growing or shrinking usage would be best served to look at the observable fees metric - though that will also become more accurate as price competition emerges on the network, and services are repriced in ETH due to fluctuating ETH price in dollar denominated terms.
After the update goes live in the coming week, the minutes streamed estimate before 8/21/23 will remain the same using the old methodology, but the minutes going forward past that point will be updated using the new methodology.
I hope that the “estimated usage” metric can still provide value to observers, despite the fact it is imperfect. The tooltip on the explorer will link to this post so that those consuming the metric have the appropriate background to interpret it correctly.