Use the input pixels in calculating the cost for transcoding
planned
Mahmoud Bahaa
Is your feature request related to a problem? Please describe.
Today the way orchestrators get paid doesn't encompass the work that is being done. Broadcasters pay per estimated decoded pixel - this means that one transcoder can do much heavier transcoding than the other and they'll still get paid the same. On the other hand, broadcasters may underpay when orchestrators transcode to a lower-quality stream.
Describe the solution you'd like
We propose that broadcasters pay for the total source + decoded pixels. We think this is a simple way to calculate the cost and would capture the work being done by the transcoders. Obviously, the pricePerPixel will need to be slashed but the benefit is that as the protocol grows and supports multiple formats, each transcoder will get rewarded fairly for their work and the broadcasters will only pay for the work being done for them.
Describe alternatives you've considered
Another option is to bill based on the maximum work done. So if the input frame is higher resolution, then orchestrators gets paid on the source frame and vice versa. We think this will be a more complicated model in terms of implementation and billing for broadcasters.
The feature was discussed and approved on Discord: https://discord.com/channels/423160867534929930/932724294230900776/1077894925569499216
Hoshi livepeer
This integration, which is a high demand from the orchestrators community (especially now that the network is much more stable and gains are reduced) and has been validated by them and the core team, is highly anticipated. Do you have an ETA for it? Perhaps the community developers could work on it if the core team is already very busy with the developments of Livepeer Studio and Catalyst?
Hunter Hillman
Hoshi livepeer: we don't have an ETA on this at the moment and it would be great for the community to play an active role in pushing this ahead. If I'm understanding the scope correctly, this can be implemented within go-livepeer.
Thom Shutt can probably point interested parties in the right direction to start working on a contribution
Thom Shutt
Hoshi livepeer The Github discussion at https://github.com/livepeer/go-livepeer/issues/2761 is a great starting point. I don't think that the code itself will be too complex, but if the community is able to put together a proposal around what this change might look like, the weightings for different inputs and how this will affect overall pricing then we can begin reviewing and discussing.
Mahmoud Bahaa
Thom Shutt: Thanks for your comment. Our proposal is to price the total source + decoded pixels, can you help me understand what other aspects do you need to kick off the discussion? Also on a high-level what parts of go-livepeer will need to change so we can have a rough idea of the change.
Thom Shutt
Mahmoud Bahaa: I'd like to see a comparison of previous + new costs for a variety of inputs
Franck Ultima Ratio
Thom Shutt: This table can already give you an idea. The objective is to have a more balanced and fair price between a 4k->1080 and 4k->480 stream, for example, since the decoding resources used are the same.
Thom Shutt
Franck Ultima Ratio: Thanks! cc Hunter Hillman
Hunter Hillman
Franck Ultima Ratio I'm having a lot of trouble interpreting this table - how do I read previous costs vs. new costs?
Franck Ultima Ratio
Hunter Hillman: Sorry, the table was originally only meant to calculate earnings for a specific type of stream. You can see a quick simulation in the bottom right corner of the table, which takes into account an average of 10 streams over 24 hours (7 in 480p, 2 in 480p+720p, 1 in 240p+360p+480p+720p).
The impact of the cost for a fixed price per pixel of 1200 wei is a factor of 4 (0.019 ETH if we only calculate the outgoing pixels, 0.085 ETH if we add the incoming pixels from a 1080P source). If the price per pixel is 600 wei, the difference compared to a price of 1200 wei that only includes outgoing pixels is a ratio of X2. I will try to create a clearer table.
In the end, the cost control will always remain with the broadcaster who sets their own price. Simply put, the difference between a 4K to 480p stream and a 4K to 1080p stream will be less significant, resulting in better revenue distribution for orchestrators based on the streams they handle.
This will also align better with the fact that the resource requirement for decoding a 4K stream remains the same, whether transcoded to 480p or 1080p.
This issue was not evident until recently because the instability of streams transitioning between orchestrators increased revenue, as even a stream received for 2 seconds would generate at least one ticket. However, now that the network is more stable, it becomes apparent that the transcoding cost must take into account the incoming stream, as it consumes a significant amount of GPU resources (VRAM).
Hunter Hillman
Franck Ultima Ratio: Thom Shutt
My perspective is that this go-livepeer change should be pushed forward by the community. If the implementation is logically coherent (based on the above, it seems to be) and technically sound, I see no reason why the community shouldn't push it forward.
Xeenon, Livepeer Inc, and other broadcasters would then be responsible for adjusting their pricing methodologies accordingly. It's not really an orchestrator's responsibility to figure out a business model for a broadcaster (though it is an orchestrator's responsibility to provide a coherent and logical payment structure).
Thom, can you or someone else with the right knowledge point the community in the right direction within the go-livepeer repo?
Franck Ultima Ratio
Hunter Hillman: here is a more readable board including another option would be to keep the current rate (1200 wei for exemple for livepeer.inc) and simply add the incoming pixels, but divided by 5. As we can see in this table, it would clearly be a much more balanced solution.
Hunter Hillman
Franck Ultima Ratio: Thanks! I agree that this is a good solution that should be pushed forward by the O community.
Thom Shutt
Hunter Hillman: Agreed on the O community leading this - I'm happy to provide support if required though, so let me know what would be helpful
Hunter Hillman
Franck Ultima Ratio Mahmoud Bahaa What info can Thom provide to help the community implement this?
Franck Ultima Ratio
Hunter Hillman Thom Shutt : I have very little knowledge of programming, so it would be preferable for a coder from the community to tackle it. However, if you can tell me which files need to be modified, I think I can try to do something using Cursor and its AI.
Thom Shutt
Previous discussion happened in Github at https://github.com/livepeer/go-livepeer/issues/2761
Hunter Hillman
planned
No ETA yet
Hunter Hillman
Mahmoud Bahaa thanks for this submission - based on the discussion in Discord I feel that there's pretty good consensus that this should happen. Before we think about prioritization, we'll do a little investigation to see
how
we can enable this behavior - I've tagged Thom belowHunter Hillman
Thom Shutt I've marked as "under review" - roughly speaking, what changes are necessary to make this happen?
Thom Shutt
Hunter Hillman: I think the steps will be
- Run some tests to determine how much utilisation increases when transcoding different quality inputs to the same set of outputs. Understand better if it's a linear increase or a curve.
- Based on (1) determine whether input complexity becomes an addition or a multiplier to our current formula.
- Run some numbers to make sure we're clear on how the financials look based on our proposal from (2)
- Make the change, update docs etc.
Hunter Hillman
under review
Papa Bear
Maybe a separate issue but certainly related as we move to more VOD work. I think we should consider how demanding the codec is to process.
For reference AWS charges ~2x for HEVC (H.265) and ~4x for AV1 vs. the price for AVC (H.264)
Hunter Hillman
Papa Bear: i generally think the Live/VOD stuff has highlighted an opportunity to get more granular with pricing (codec, type, resolution, etc).
I'd advocate for you to open a separate request for this - it's a big question on its own
Papa Bear
Hunter Hillman: Will do when I'm back at my desk. I think Ivan's comments in the original github request are a great starting point so I'll include them as well.