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