Allow distinct Pricing for VOD and Live Streams per Broadcaster in `pricePerBroadcaster`

[rickstaa]

Problem Statement:

There's a growing need, as highlighted by sundara.eth on Discord, for broadcasters to have the flexibility to set different pricing structures for Video On Demand (VOD) and Live streaming services. Currently, the pricePerBroadcaster CLI argument does not support this level of granularity.

Proposed Solution:

I propose enhancing the go-livepeer binary to support distinct pricing for Video on Demand (VOD) and Live streaming (LIVE). Specifically, it would be beneficial if the binary could interpret the following JSON structure, allowing orchestrators to set separate prices for VOD and Live streaming jobs:

{
    "broadcasters": [
        {
            "ethaddress": "0x68d6FF3938Ff63d2df16567Cb8CA9772e14496F7",
            "priceperunit": {"VOD": 10, "LIVE": 50},
            "pixelsperunit": 1
        }
    ]
}

This JSON structure is intuitive and aligns well with the existing framework, offering a straightforward way for orchestrators to specify their pricing across jobs. Naturally, this feature must be implemented to maintain backward compatibility with the current syntax (e.g., "priceperunit": 0).

Alternative Solutions Considered: (Describe any alternative solutions or features you have considered, if any)

Additional Context: (Include any additional context or screenshots about the feature request here, if applicable)

[leszko]

@rickstaa Thanks for raising this issue. This feature would be very helpful.

Some things to consider:

• How could we distinguish the Broadcaster's ingest if it's Live or VOD? In other words, a segment comes to B and should it use Live or VOD pricing? 🤔
• Do we want to make it extensible to support any other type, not only VOD and Live? I can imagine other scenarios, like charging more for low-latency transcoding. Or by using CPU transcoding?
• I think it is somehow related to capabilities and job abstraction, in general in the Livepeer network could do different kind of jobs and charge for them differently

[thomshutt]

What about if we spun up a separate Broadcaster address for Livepeer Studio's VOD broadcaster? That would allow setting different prices with the current app capabilities

[ericxtang]

Interesting to consider VoD and Live as different job types, especially given the different performance requirements.

Live needs to be transcoded under real-time. VoD doesn't have that requirement, and can be parallelized across multiple GPUs at once. As the software & service matures, these optimizations will need to be made.

[rickstaa]

@rickstaa Thanks for raising this issue. This feature would be very helpful.

Some things to consider:

• How could we distinguish the Broadcaster's ingest if it's Live or VOD? In other words, a segment comes to B and should it use Live or VOD pricing? 🤔
• Do we want to make it extensible to support any other type, not only VOD and Live? I can imagine other scenarios, like charging more for low-latency transcoding. Or by using CPU transcoding?
• I think it is somehow related to capabilities and job abstraction, in general in the Livepeer network could do different kind of jobs and charge for them differently

Thank you, @leszko, @thomshutt and @ericxtang, for your patience and valuable input.

You've raised a crucial point regarding the differentiation between Live and VOD content for pricing purposes. I haven't fully explored this feature request to consider these specifics yet, but recognizing the broadcaster's ingest type is an essential factor to address 👍🏻.

On the topic of making our system extensible to support types beyond just VOD and Live, I agree that this flexibility could be beneficial. Envisioning scenarios like premium charges for low-latency transcoding or different charges for CPU-based transcoding opens up a broader range of services we could offer. This discussion aligns with the wider concept of capabilities and job abstraction within the Livepeer network, allowing for a diverse array of jobs and variable charging models, as outlined in the forum discussion on job abstraction.

The idea of starting with VOD and Live as foundational categories are indeed intended as a proof of concept to enhance our Job Abstraction pipeline. The development of the AI SPE by @yondonfu's team exemplifies another scenario where distinguishing between job types becomes crucial. Furthermore, incorporating additional information to identify specific clients or broadcaster deals with orchestrators, as mentioned in my Discord comment, could significantly optimize our network's functionality and service delivery.

[rickstaa]

What about if we spun up a separate Broadcaster address for Livepeer Studio's VOD broadcaster? That would allow setting different prices with the current app capabilities

@thomshutt I concur that this represents a commendable intermediate solution with minimal resource requirements 👍🏻. It is similar to @titannode's suggestion in the forum post. Nonetheless, I firmly believe that embedding this capability within the protocol itself is imperative for the advancement of the ecosystem, offering benefits on a broader scale.

[yondonfu]

FWIW I think a pricing framework [1][2] that can continuously adjust the price for a job based speed of completion and use of certain features for transcoding makes more sense in the long run than having distinct flat prices for VOD vs. Live - a B may be using the output for VOD or Live, but ultimately what it would be paying O for is a certain speed and configuration of transcoding that is appropriate for that setting.

[1] Defining this is the exercise that remains. [2] This is in a different domain, but see https://github.com/graphprotocol/agora/blob/main/docs/README.md for an example of a pricing framework that attempts to adjust prices based on the shape of a GraphQL query

[ad-astra-video]

We are overlapping on this in the AI video build out right now. I think this can be done with adding a LIVE and VOD capability that is set by the Transcoder. The Orchestrator would then allocate jobs to the Transcoders that pass up the VOD or LIVE capability to the Orchestrator when it connects. Transcoders could have flexibility to use separate hardware for VOD by having launch flags that default to enabling VOD and LIVE jobs to be completed. Then if the Orchestrator wants separate hardware for VOD and LIVE jobs they can switch the flags to turn off one of those capabilities on the Transcoder. Example of this would be a LIVE Transcoder in same server in datacenter as Orchestrator (or really close) and more freedom to place VOD hardware in cheaper locations to support lower prices.

The Gateway update is relatively straight forward to add the VOD or LIVE capability in the GetOrchestrator request. The ai-video branch has already built out updating the GetOrchestrator request to include capabilities and uses it with the AI workflow to select Orchestrators.

For pricing, some of this is built out with the maxPricePerCapability I implemented thinking a price could be set for each capability (e.g. H264, HEVC, AV1) and capability prices could be set individually and chained together if wanted by the Orchestrator. The maxPricePerCapability that is in PR #3116 calculates a total price for the capabilities requested. If no price set for any capabilities requested it uses the pricePerUnit set with launch flag.

Plan is to also add a pricePerCapability for orchestrators to set as well. Its possible this could replace the pricePerGateway generic pricing we have now completely. The Orchestrator pricePerCapability will re-use the framework that the maxPricePerCapability uses since the only additional field for the Orchestrator is being able to set different prices for different gateways.

Interested in any thoughts on this.

[j0sh]

For pricing, some of this is built out with the maxPricePerCapability I implemented thinking a price could be set for each capability (e.g. H264, HEVC, AV1) and capability prices could be set individually and chained together if wanted by the Orchestrator

Having more fine grained pricing makes sense. On the video side, we will almost certainly want different pricing for different codecs. From my testing so far, HEVC encoding is roughly 2-2.5x slower than the equivalent H.264, and AV1 will probably be even slower.

It might be helpful to think about the VOD / live distinction in terms of latency expectations or even priorities. For example, with a just-in-time transcoding scheme where transcodes are initiated only on a playback request, a VOD stream would have similar latency requirements as a livestream - you do not want transcoding to fall behind the play head. Moreover, ahead-of-time VOD transcoding configurations will typically prioritize compression or image quality over latency - which usually ends up being more expensive to process computationally. So maybe a broadcaster can pay a little less for sitting in a queue, while end up paying more for the actual work. (This suggests to me that live / VOD pricing could essentially be a wash)

I don't have any concrete suggestions right now, except that a live-or-vod flag feels coarse when the problem space is actually quite nuanced.

Example of this would be a LIVE Transcoder in same server in datacenter as Orchestrator (or really close) and more freedom to place VOD hardware in cheaper locations to support lower prices.

FWIW, the way I think about VOD-vs-live latency is this: you are either OK sitting in a queue waiting for your job to be transcoded, or you want someone to pick up your work immediately. Beyond that, network latency between B-O is quite localized and sensitive to overall conditions (it is possible that a GPU in a cheaper location may end up with better connectivity to a broadcaster) that I am reluctant to use "network latency" alone as the basis for a pricing knob. That being said, there is probably room to optimize the flow between B-O, certainly with pricing and/or "transcoding priority" as inputs, but this feels like an area that falls more on the broadcaster (and corresponding O discovery / selection scheme) than anything the O can definitively offer.

[thomshutt]

Really good points @ad-astra-video and @j0sh. My 2 euro cents:

• We currently pay based on pixels. What we really want to pay for is "complexity" - i.e how long a job takes to complete / how much compute resource it ties up. I think that trying to start factoring in codecs involved, quality etc. will overcomplicate it on both the B and O side but also agree that "Live / VOD" or even "per Broadcaster" is starting to feel too coarse.
• There's currently a lot more supply than demand on the network and so I don't think we need to factor in the concept of job priority for now. That might change in the future.
• Livepeer Studio is still the main driver of traffic to the network and so the concept of a Live broadcaster and a VOD broadcaster with different addresses still works. This will change in the future if Broadcasters join the network that want to process both job types.

My proposal:

• Livepeer Studio updates its VOD Broadcaster to use a different address, allowing Orchestrators to set prices differently for different job types / to opt out of a particular type.
• We make new codecs have a "multiplier" in the payments calculation. This doesn't factor in to the Maximum Price calculations, so a B will offer a price to an O in exactly the same way as now and then this will be multiplied by e.g 1.2 for HEVC or 1.5 for AV1 to determine what price is actually paid. These factors won't be configurable to begin with and Os can opt out by setting their HEVC / AV1 capabilities to false if they don't feel like it's a fair multiplier

[ad-astra-video]

I agree re the latency vs increased compression/quality may end up being a wash overall. Orchestrators still may be able to help achieve lower prices for VOD but not certain that would be across the board.

Beyond that, network latency between B-O is quite localized and sensitive to overall conditions (it is possible that a GPU in a cheaper location may end up with better connectivity to a broadcaster) that I am reluctant to use "network latency" alone as the basis for a pricing knob.

Orchestrator can only have one instance per region served because the randomly generated secret used in the auth token will cause streams to fail if switched to a failover. This could be the case for O-T but the assumption is the Ts used for LIVE transcoding would be meaningfully closer to the Orchestrator. Using my setup as an example, for USA I have 3x GPUs in the datacenter server the Orchestrator runs on and have 3-6x available off site as backup transcoders if needed. The backup Ts are close enough to do realtime transcoding still but the Ts on the same server are faster.

Overall, Orchestrators are less interested in changing pricing for VOD vs LIVE and more interested in a way to allocate VOD jobs differently than LIVE jobs to better manage the load the VOD jobs put on the Transcoders (e.g. VOD segments can be 2-5x longer than LIVE segments). I was thinking adding a VOD or LIVE capability to the request from the B would be a somewhat lighter lift to get different pricing that could benefit the Gateway and allow Orchestrators to allocate jobs differently to better manage the Transcoders load since the Orchestrator already searches for Transcoders by capabilities. The lighter go-livepeer lift may cause more work upstream though. My knowledge of the upstream is very limited so I am not sure what the upstream work would be for this update.

We currently pay based on pixels. What we really want to pay for is "complexity" - i.e how long a job takes to complete / how much compute resource it ties up. I think that trying to start factoring in codecs involved, quality etc. will overcomplicate it on both the B and O side but also agree that "Live / VOD" or even "per Broadcaster" is starting to feel too coarse.

Agree, there has to be a line somewhere or we will all be managing pricing more than actually getting the job done. I have been able to provide my stream tester at lower cost to me with the pricePerGateway so would like to keep that if possible or some version of it (understand this is not a overall network reason but wanted to mention it).

B will offer a price to an O in exactly the same way as now and then this will be multiplied by e.g 1.2 for HEVC or 1.5 for AV1 to determine what price is actually paid. These factors won't be configurable to begin with and Os can opt out by setting their HEVC / AV1 capabilities to false if they don't feel like it's a fair multiplier a B will offer a price to an O in exactly the same way as now and then this will be multiplied by e.g 1.2 for HEVC or 1.5 for AV1 to determine what price is actually paid. These factors won't be configurable to begin with and Os can opt out by setting their HEVC / AV1 capabilities to false if they don't feel like it's a fair multiplier

I think this is fair but some transcoding tests or market pricing to support the multipliers would be nice to see in the messaging at launch of this. That said, I would provide transcoding for those multipliers at launch so could also be an adjust as it goes kind of thing.

These factors won't be configurable to begin with and Os can opt out by setting their HEVC / AV1 capabilities to false if they don't feel like it's a fair multiplier

I also like this for the enhanced job routing for Orchestrators. One scenario I can think of is I may want my AV1 capable GPUs to focus on AV1 transcoding and can run multiple T processes to adjust the capacity served to AV1 and the rest of the codecs for each GPU as transcoding needs change over time.