Fair Pricing for Transcoding Jobs: Accounting for Pixel and Capability Requirements
under review
Papa Bear
In addition to pixel count we should also consider the varying computational demands of different codecs, i.e. H.264 and H.265, where H.265 decoding and encoding can be 2-5 times more computationally expensive than H.264. If we look at AWS as an example they charge 2x to transcode H.265 compared to H.264. Figuring out a method to charge for the compute demands of a job will also be useful for add-on features such as scene detection, watermarking, etc.
Ivan Poleshchuk has proposed a formula to calculate the transcoding job cost in this post https://github.com/livepeer/go-livepeer/issues/2761#issuecomment-1440466702
AWS pricing https://aws.amazon.com/mediaconvert/pricing/
Chris Hobcroft
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.
Perhaps there are also more-advanced ways to evolve Livepeer's fee market, by researching research into Ethereum's fee market in Proof-of-Stake and EIP-1559 mechanisms, or even through Liquid Staking Derivatives like Tenderize. How can we invent a new game?
Thought experiment: how will Orchestrators charge for rendering AI-generated art? Per-pixel ain't gonna cut it any more.
Chris Hobcroft
Here is some literature about the gas required to perform certain opcodes on Ethereum:
https://ethereum.org/en/developers/tutorials/yellow-paper-evm/
https://ethereum.org/en/developers/docs/evm/opcodes/
In a way, it feels like we could use ffmpeg as a basis for costing up services, if we can come with a rationale for how much to charge per unit of processing for each ffmpeg capability. Consider that when transcoding, we are using "Simple scaling" as defined in this: https://trac.ffmpeg.org/wiki/Scaling and then also consider everything else that ffmpeg can do: https://trac.ffmpeg.org/wiki
Hunter Hillman
under review
Hunter Hillman
xpost from discord - I encouraged Papa Bear to create a new post for this request:
the reason I did this was because I wanted to separate concerns: at first glance I don't think the pixels update requires a wholesale update to the pricing model, whereas the other dimensionality that PapaBear mentioned would.
Paying for the total source + decoded pixels is simpler within the current system - it's just different math. Color profiles, resolutions, etc would require much more functionality for both Bs and Os (new price discovery mechanism, new price-setting mechanism, etc)