Use the input pixels to calculate the cost for transcoding

[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.

Additional context The feature was discussed and approved on Discord: https://discord.com/channels/423160867534929930/932724294230900776/1077894925569499216

[FranckUltima]

It is clear that it would be much fairer. When the capacity of a node are mobilized to transcode 4K30 or 4K60 (or more) into 244p or 360p, and it is paid only for encoded pixel, it is true that it is not very fair. This solution seems to me quite fair and adapted to the differents uses of Livepeer.

[AuthorityNull]

It would make a lot of sense to calculate decode as well as encode, especially with VOD since it's seems to utilize the dec chip more than the enc.

[mahmoud-bahaa]

Created another feature request as advised by the Livepeer team: https://livepeer.canny.io/feature-requests/p/use-the-input-pixels-in-calculating-the-cost-for-transcoding

[chrishobcroft]

I support the general gist of this issue, and believe it will become more important in near future as source resolutions start to increase to 4K and 8K.

Based on current mechanism, an O gets paid the same for transcoding 240p into 144p as they do for transcoding 8K into 144p. This doesn't feel appropriate.

One question I do have is around how to accurately model the actual costs associated with doing the work.

For example, is it 4x harder to transcode [2160p to 144p] than it is to transcode [1080p to 144p] because there are 4x the number of pixels to process? It feels like it might be roughly right, but then what do I know about how GPUs work? (not much).

I feel that this issue would benefit from some research into the deeper mechanics of how transcoding happens.

[papabear99]

Another thing to consider is 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)

[cyberj0g]

Great proposal! I think, the most fair approach would be to estimate the price based not just on pixels, but also on capabilities requested for the job. For example, H.265 decoding and encoding may be 2-5 times more computationally expensive, compared to H.264. Someday, non-codec capabilities, like content detection, may be added as well. The formula to calculate the transcoding job cost should be something like:

$Cost = \sum\limits{i=1}^{N{caps}} (CapabilityPricePerInputPixeli * N{InputPixels} + CapabilityPricePerOutputPixeli * N{OutputPixels})$

Above formula should also account for the fact that decoding is done once per job. To simplify node configuration, we can continue using just the pricePerPixel setting, and set appropriate complexity multipliers as the constants in the code (based on testing with actual hardware). For example, we may use H.264 high profile as "base", with complexity of 1, and set H.265 encoding complexity to, say, 3:

H264_InputPixelPriceMultiplier = 1
H264_OutputPixelPriceMultiplier = 1

H265_InputPixelPriceMultiplier = 2
H265_OutputPixelPriceMultiplier = 3

SomeAIStuff_InputPixelPriceMultiplier = 10
SomeAIStuff_OutputPixelPriceMultiplier = 0

[chrishobcroft]

Given the potential for myriad other services being provided for Orchestrators to supply, is there some sense in defining some kind of concept like "gas" in Ethereum? With gas usage calculated based on source resolution, and output resolutions.

[papabear99]

Given the potential for myriad other services being provided for Orchestrators to supply, is there some sense in defining some kind of concept like "gas" in Ethereum? With gas usage calculated based on source resolution, and output resolutions.

That's an interesting concept. Livepeer has moved feature requests over to https://livepeer.canny.io/feature-requests

Would you mind sharing the gas concept in this request https://livepeer.canny.io/feature-requests/p/fair-pricing-for-transcoding-jobs-accounting-for-pixel-and-capability-requiremen

[chrishobcroft]

I think I did it.

[ad-astra-video]

Great proposal! I think, the most fair approach would be to estimate the price based not just on pixels, but also on capabilities requested for the job. For example, H.265 decoding and encoding may be 2-5 times more computationally expensive, compared to H.264. Someday, non-codec capabilities, like content detection, may be added as well. The formula to calculate the transcoding job cost should be something like:

Cost=∑i=1Ncaps(CapabilityPricePerInputPixeli∗NInputPixels+CapabilityPricePerOutputPixeli∗NOutputPixels)

Above formula should also account for the fact that decoding is done once per job. To simplify node configuration, we can continue using just the pricePerPixel setting, and set appropriate complexity multipliers as the constants in the code (based on testing with actual hardware). For example, we may use H.264 high profile as "base", with complexity of 1, and set H.265 encoding complexity to, say, 3:

H264_InputPixelPriceMultiplier = 1
H264_OutputPixelPriceMultiplier = 1

H265_InputPixelPriceMultiplier = 2
H265_OutputPixelPriceMultiplier = 3

SomeAIStuff_InputPixelPriceMultiplier = 10
SomeAIStuff_OutputPixelPriceMultiplier = 0

Can these multipliers be configurable by each orchestrator for each broadcaster? I am not certain of the logic flow in the go-livepeer code so understand if first iteration is implementing the multipliers hard coded which could be changed and new binaries built. Thinking they could be added to the priceInfo logic but also believe the broadcaster would need to provide more information on the job requested in the GetOrchestrator rpc call to accurately provide a price. Maybe I am thinking of this backwards though and the pricePerPixel could be added to the Capabilities sent in the OrchestratorInfo response to the broadcaster.

[cyberj0g]

@0xb79 these multipliers would represent resources required to perform the job, compared to the baseline. While specific values may slightly differ depending on specific transcoder hardware, I don't think it's practical for orchestrators to configure them individually.

One feasible scenario I can think of for per-O complexity configuration is to restrict unwanted job types by setting some prohibitive complexity level. It's best to achieve that more explicitly, through advertised capabilities, and not the prices. We don't have an option to configure these now, but the logic is there.

[ad-astra-video]

@cyberj0g I think that makes sense. If a specific price is wanted for a B it can always be calculated to achieve the target an O wants by putting a simple calc together and include consideration for the multipliers with the pricePerBroadcaster.

[thomshutt]

I'm going to close this issue since we're now moving to Canny for tracking feature requests and this is at https://livepeer.canny.io/feature-requests/p/use-the-input-pixels-in-calculating-the-cost-for-transcoding

I've cross-referenced this issue in Canny so that the discussion we've had so far isn't lost.