A guide for determining Price Per Pixel

Transcoders
1

Hi all

With the recent updates to the price weight factor in the default selection algorithm it is now up to the free market of Orchestrators to set their price in a competitive manner.

There are several implications for free market dynamics and the motivations for setting a price for each Orchestrator.

Some Orchestrators will set their price based on other participants in the market (whether at a loss or not) in order to gain work.

Others will calculate their cost of infrastructure and set a price based on a formula for profit.

I think we have mostly explored the former option since the launch of the new selection algorithm about 2 months ago, but this post is to focus on the latter option of providing a tool for helping Orchestrators reach a profitable operating model.

I hope by providing tools like this it will help educated the market on how to set our price and move the Orchestrators into a more healthy and sustainable operation.

Here is a link to some formulas for calculating cost for determining your price per pixel.

Feel free to use the link below, copy and paste into your own sheet and adjust as needed. You can adjust the “Number Of Streams”, “Price Of ETH”, "“Price Per Pixel” variables to see how well your setup scales.

A breakdown of each sheet and their formula:

Self Host – A GPU hosted at home with unlimited bandwidth and no extra costs.

Rented GPU – A rented datacenter GPU, $0.01 per GB of bandwidth and $249/mo for rental.

Pool Standalone Cost Per GB – A pool setting where the bandwidth is doubled since it sends and receives the stream twice at $0.01 per GB, basics VPS of $24/mo, and a 20% cut from GPU retained by the pool operator.

Pool Standalone Unlimited GB – Same as above but free bandwidth with a larger VPS of $400/mo.

Screenshot:

Price Per Pixel
Price Per Pixel1582Ă—659 20.3 KB

4 Likes
2

Thanks Titan!

Another simple approach to optimize your ppp: Track your total “Ticket Value Received” for various ppp.
With this metric you’ll see if the additional streams from a lower ppp are worth it or not (in my experience, a very low ppp is not worth it).
Track it in Grafana with increase(livepeer_ticket_value_recv[1d])/10^9 over multiple days and compare.

1 Like
3

Very good point, I’m not sure how to incorporate that into the spreadsheet but there is likely some sort of bell curve for “streams to tickets” that would play a role in the calculation as well.

1 Like
4

Vires is right.
Currently, the only thing that allows fixing a price per pixel is: at what point by increasing the price do I start earning fewer tickets?
Regarding Ultima, this revolves around 150 PPP.
For now, the price is only an adjustment variable to compensate for the difference in stake between orchestrators.
No orchestrator today sets its price based on the quality of service it can offer, and no broadcaster chooses it for its services.
If you have a large stake, you can keep a high price, if you have a small stake, your balance is at a very low price.
In short, you can charge a lot if you have a large stake and work for little if you have a small stake.

5

Do you really get a lower ticket value once you go above 150 PPP? Seems surprisingly low.
It’s not about the amount of tickets, but about the value of tickets. You will get less tickets at 300 PPP, but they’re worth more - so in the end you might have a higher expected payout.

I’m at 750 PPP now and the ticket value is even higher than at 450 PPP (granted there also seems to be more work on the network since a few days). Might also be because of the stake difference.

1 Like
6

Yes, I’m really trying to find the balance at which the PPP is most fair for my node.
Of course, there are elements that I don’t control and that change regularly, such as the PPP of other orchestrators and demand. For demand, I try to compare over periods of equivalent demand and over periods long enough to be relevant. And for the price of other orchestrators, I try to re-test regularly.
For now, it’s really the balance point for me.
I also made a Python script to dynamically change the price based on the number of streams, but I haven’t found a way to change the price without going through the CLI yet, so it’s a bit cumbersome to set up.

7

Unless I am mistaken, changing the PPP does not change the face value of each ticket.
Only changing the Maxfacevalue can change its value (on orchestrator’s side).
Changing the ticketEV changes the number of tickets received and their chances of winning, but not the face value.
Therefore, regarding the PPP, the number of tickets received is a good indicator.
Another thing that also plays a role is that the majority of streams are transcoded in 480p or 720p, and the 1080p and other streams, which pay the most, are rarer. Therefore, by increasing the number of streams received, we also increase the chances of receiving a higher quality stream, and thus ultimately the number of tickets received.
I had also proposed some time ago to integrate the decoded pixels into the cost calculation, since 4K can be decoded very well for transcoding into 480p. And only the transcoded pixels are billed, while the GPUs are heavily used for decoding.

Integrating the decoded pixels would reduce the price difference between the largest and smallest streams received (While maintaining a clear price difference between SD and HD transcoding.), and accurately calculate the total price of transcoding based on the actual capacity requested from the orchestrators.

1 Like
8

Yes, you’re correct regarding the amount of tickets. I always get confused with the ticket calculation and somehow had the impression that the ticketEV gets adjusted by the B according the the PPP - but that’s not the case (yet at least).

Your chances on a 1080p streams stay the same (e.g. a 10% chance). But if you process more streams you will have more 1080p streams but they also generate less value due to a lower PPP. So that factor shouldn’t matter in the long term.

You can use
curl -X POST -d "pixelsPerUnit=1&pricePerUnit=xxx&broadcasterEthAddr=default" http://127.0.0.1:7935/setPriceForBroadcaster
to set your PPP without having to go through the CLI

5 Likes