[Video Disruptor] New monetization model for Orchestrator and streamers(Broadcasters) with ads-stitching support on Livepeer Node(Go-Livepeer) : Dynamic ads(video) insertion(Server side ads insertion).
Opened this issue · 16 comments
Application by: eneche0343
What is your project, and what problem does it solve?
Ad-free streaming challenges creators' revenue and viewer accessibility, shifting focus to alternative monetization(subscription, donations), potentially impacting content quality.
By implementing dynamic ad insertion, creators (broadcasters) and orchestrator can maintain a stable revenue stream through targeted, non-intrusive ads. Thus viewers can benefits/access more free or low-cost content.
Link to public GitHub repo (if applicable)
https://github.com/livepeer-ssai
Link to demo website (if applicable)
https://www.loom.com/share/003c95df4af641399cf7c9ddb22f6b63?sid=707a434c-7a1d-410c-bbe7-b4762c9eb2dc
Please describe in more detail why this proposal is valuable for the Livepeer ecosystem
Livepeer excels in transcoding but lacks effective content monetization, unlike ad-supported Web2 platforms enabling free viewing and diverse creator monetization.
- Dynamic ad stitching in Go-livepeer allows targeted ad insertion, empowering creators with revenue and enhancing user engagement in video content.
- Orchestrators incentivized by ad earnings can offer cheaper compute fee.
Please describe in details what your final deliverable for this project will be.
- Dynamic Ads-insertion(Server-side ads insertion) functional and fully built into Go-livepeer(Ads-publisher). My team plans on extending Go-livepeer with an additional capability of inserting ads into transcoded streams. This job type will stitch video content and ads into a single stream, independent of a web page or app.
- A extended Livepeer video player with ad skip click.
How will this deliverable benefit the Livepeer ecosystem?
Livepeer excels in transcoding but lacks effective content monetization, unlike ad-supported Web2 platforms enabling free viewing and diverse creator monetization.
- Dynamic ad stitching in Go-livepeer allows targeted ad insertion, empowering creators with revenue and enhancing user engagement in video content.
- Orchestrators incentivized by ad earnings can offer cheaper compute fee.
Please break up your development work into a clear set of milestones
Number | Description | Deliverable | Amount | Start Date | End Date |
|---|---|---|---|---|---|
3 | Deployment of the ads extended Go-livepeer node on cloud service( Linode). My team will host and run two of this new extended orchestrator node as part of the Livepeer network. 1 Cloud and devops engineer. |
| $2,000.00 | 2/11/2024 | 2/29/2024 |
1 | A Proof of Concept (POC) for integrating server-side ad insertion and stitching on Go-livepeer.This will include demonstrating the feasibility and functionality of seamlessly inserting advertisements into video streams processed by Go-livepeer. Three backend developers |
| $6,500.00 | 11/30/2023 | 1/14/2024 |
2 | An extended Livepeer video player with full on support for ads break and play with skippable ads click. The player will have the function to skip ads on click. Two frontend developers and one backend |
| $3,500.00 | 1/15/2024 | 2/10/2024 |
What is the total amount requested (in USD)?
12000
Specify your team's long-term plans to maintain this software and upgrade it over time
The project will be open-source and maintained by the me and the team . The core team will be responsible for fixing bugs, adding new features, and upgrading the node over time.Overtime we plan to expand the team with more developers .
We need these nodes ourselves,our long term plan is to build a decentralized Ad network built solely in connection to Livepeer orchestrator as ad publishers.
Please describe (in words) your team's relevant experience, and why you think you are the right team to build this project. You can cite your team's prior experience in similar domains, doing similar dev work, individual team members' backgrounds, etc.
I am a software and blockchain engineer with over 5 years of working experience , with keen interest in dapps development, cloud and media tech stack.
I have been in the past, a multi prize winner in different hackathon hosted by the Encode community including the Next video build hackathon 2022/2023.
I also made a lot of open source contributions, most recently to the Azuro network( Blockchain powered betting engine) in the last Encode X Gnosis hackathon.
I and my team have spent the past months researching dynamic ads insertion on different platforms like Google and Amazon. From this research we had worked on some samples that are now available on how github repository. We took several weeks to understand the Go-livepeer codebase architecture and running local instance and testing.
My team members(6) are well proficient in their stacks and have been involved in several enterprise level projects in the past and are very keen in using their experience to make innovative improvement on the Livepeer network(Go-livepeer).
Who is your target user group? How do you plan on getting your users to use this?
Targeted user group are orchestrator and streamers. We plan on hosting AMA and spaces on X(twitter ) and the Livepeer discord community to introduce and explain the benefit of the extended Go-livepeer node.
How did you learn about the Livepeer Grants Program?
Livepeer discord community .
Was this project started at a hackathon or another web3 event? Which one?
No
Please include any additional information that you think would be useful in helping us to evaluate your proposal.
My team vision is to build and run an Ad network solely in connection with the Livepeer orchestrators as our publishers. This means the only recognized publishers on our network is an orchestrator with an account.And the only form of publishing media are video assets.This new job type on the node is a major step towards this.
We are very interested in the Catalyst hacker group and the future plan is to integrate our ad manager on Studio(Catalyst) .
First off, I absolutely love this idea. The fact we can utilize Livepeer to serve ads from a decentralized infra layer is super compelling. Serving up ads with web2 platforms like Amazon or Google might be a good first mvp to get the ball rolling and paying the streamers. Later switching to a web3 solution like Brave Rewards might be something to source ads from. And like you said the end goal is to have our own native ad platform on Livepeer could be super powerful.
I have a couple questions about the integration you are describing above.
-
Since the ad insertion works at the catalyst node (as mentioned at the water cooler chat), does that mean the ad is just an overlay for the live video content?
-
If so, this would mean the ad insertion doesn’t actually get processed by the orchestrator since it doesn’t need to be transcoded. Or would the catalyst node send the ad to the Orch to be permanently stiched into the video?
-
And if that is the case how would a person skip the ad?
Overall I love the idea, can't wait to see this type of revenue stream enter the Livepeer developer space.
👏
I love the idea ❤️
Also, I completely agree with @Titan-Node that this idea is great, but we should specify here how it should work from the technical perspective.
We have the following flows:
- Watching transcoded video: Streamer -> Catalyst -> Orchestrator -> Viewer
- Watching source video: Streamer -> Catalyst -> Viewer
Which part in these flows inserts the ads? My initial reaction is that we want to allow Catalyst to not pay Orchestrator for the transcoding, but then Orchestrator is allowed to insert ads. Is that the idea? Then, how do we skip ads from the player (and should we allow it at all)?
Hey Guys ,thanks for the feedback .
To clarify the ideal/implementation for ads skip with the player has only be thought for VOD . The ideal is to navigate to relevant content on the video when a user interact with the skip button. The manifest manipulator will have markers for ads and the point of their insertion. Skipping just means moving along the manifest.
I love the idea ❤️
Also, I completely agree with @Titan-Node that this idea is great, but we should specify here how it should work from the technical perspective.
We have the following flows:
- Watching transcoded video: Streamer -> Catalyst -> Orchestrator -> Viewer
- Watching source video: Streamer -> Catalyst -> Viewer
Which part in these flows inserts the ads? My initial reaction is that we want to allow Catalyst to not pay Orchestrator for the transcoding, but then Orchestrator is allowed to insert ads. Is that the idea? Then, how do we skip ads from the player (and should we allow it at all)?
Hi @livepeer-ssai Team,
Thank you for the insightful discussion on your grant proposal ❤️🔥! Initially sceptical due to my preference for subscription models over ads, your presentation effectively highlighted the potential benefits of an ad-based revenue model for the ecosystem. It's clear how this could support new streamers and provide additional income for orchestrators 🚀.
Although I'm considering a starter budget for streamers/broadcasters as detailed in my orchestrator roadmap, I acknowledge the potential advantages of your proposal for the ecosystem. So, I've shared some feedback below to help you understand your proposal.
Key Points for Consideration
- Demand and Impact Assessment: Providing statistics or case studies demonstrating the extent of the fee challenge for broadcasters and streamers would be valuable. This information is crucial to understanding how the feature might enhance these users' adoption of the Livepeer platform.
- Ad Implementation Strategy: A comparative analysis of client-side vs. server-side implementation would be valuable. Initially, I anticipated a client-side middleware approach. Understanding the trade-offs between these strategies is crucial.
- Integration with go-livepeer: Assessing whether to integrate directly into the go-livepeer binary or as a separate plugin (e.g., via a
--plugin ad-injectionflag) is essential. Consideration of the additional code and its impact on the binary is important. Ultimately, this decision rests with the @livepeer team, but your insights would be beneficial. - **Server Load and Bandwidth Impact: ** You must estimate how your solution will affect server load and bandwidth.
Additional Points that were brought up in the Watercooler chat:
- Ad Regulation Compliance: Strategies for adhering to local ad regulations on the server side (e.g. https://business.gov.nl/regulation/advertising/).
- Targeted Ad Serving: Approaches for serving targeted ads and accommodating advertiser bids.
- Ad Serving for Different Job Types: Detailed ads-serving plans in VOD vs. Live scenarios. While server-side product placements (like animated banners or AI-enhanced brand placements) seem viable, client-side ad stitching offers notable advantages (e.g., dynamic targeting and scalability). If you choose server-side stitching, could you provide metrics on the extent of ad-blocking issues and their impact? The product placement example provided by @Titan-Node in the watercooler chat illustrates an excellent use case for server-side ad injection, highlighting its potential effectiveness in specific scenarios.
I'm looking forward to more developments on this proposal.
@livepeer-ssai Thanks a lot for the more details and the slide deck. It explains a lot. Your solution makes sense for Livestreams, but not necessarily for VOD. Am I correct? The reason why I think it's not a fit for VOD is that:
- You'd hardcode the ad into the VOD and the ad may not be up-to-date anymore
- It'd be straightforward to skip the ad by skipping a few segments
Saying that, I think for Livestreams it makes a lot of sense. My main concern is the protocol security. Imagine the following scenario:
- Catalyst (Broadcaster) sends a video to Orchestrator and says ("hey, transcode it for me for free, but you're allowed to add ads)
- Orchestrator transcodes the video and insert ads
- Catalyst could easily remove the ads and therefore achieve free transcoding.
I think this is something we need to address.
So besides my concerns of the teams ability to actually implement this proposal, I think there's a bit of a lack of understanding on how go-livepeer works in the context of the full media-pipeline which for example Livepeer Inc runs:
- it groups creators and Broadcasters together which should be seen as separate entities
- viewers don't view from Orchestrators, but Orchestrators send transcoded segments back to the Broadcaster which then handles content delivery. Viewers don't view from B nodes as well, but rather to a CDN or in the case of Livepeer Inc to Catalyst nodes
Then there's the point of where and how to insert these ads. An Orchestrator can't simply transcode ads into the video and have this tied to viewership metrics. They would also be permanently embedded into the stream, including any clippings or recordings. Any views of the recorded or clipped content will definitely not be counted as a viewer from the ad providers' perspective. Since the Orchestrator only does transcoding of individual segments, this is the only method which can be implemented on the O level.
Dynamic ad insertion is a tight interplay between the client-side app and the media server serving the stream, so outside of the scope of the B/O/T nodes. It would be a fairly significant change to modify this workflow to have the O transcode this into the stream on request and then they still have to trust that ad sessions get created and handled correctly by the B
Then there are other technical issues like how to deal with the source track, which no player will be able to sync with the transcoded tracks unless the source track also gets transcoded. This would be costly and would not work for a low-latency protocol like WebRTC
Besides all of the technical hurdles to have ads be a monetisation model for the Orchestrator, it doesn't even makes sense to me. Why wouldn't the B just pay the transcoding fees and do the ads themselves? Do content creators ven want to use a platform which inserts ads on their content without them getting a cut?
Besides all of the technical hurdles to have ads be a monetisation model for the Orchestrator, it doesn't even makes sense to me. Why wouldn't the B just pay the transcoding fees and do the ads themselves? Do content creators ven want to use a platform which inserts ads on their content without them getting a cut?
@stronk-dev, excellent points 🙏🏻. I concur with your perspective. While I understand the proposal team wants ads managed through the backend to prevent adblocking, my preference leans towards their implementation on the streamer or broadcaster side as middleware. I do not know if there is a need for such middleware, given that the ad providers already provide many tools for front-end applications to serve ads. This approach would avoid the overcomplication of Livepeer's core codebase. The streamers or broadcasters could then use the income from these ads to pay the orchestrators.
So besides my concerns of the teams ability to actually implement this proposal, I think there's a bit of a lack of understanding on how go-livepeer works in the context of the full media-pipeline which for example Livepeer Inc runs:
- it groups creators and Broadcasters together which should be seen as separate entities
- viewers don't view from Orchestrators, but Orchestrators send transcoded segments back to the Broadcaster which then handles content delivery. Viewers don't view from B nodes as well, but rather to a CDN or in the case of Livepeer Inc to Catalyst nodes
Then there's the point of where and how to insert these ads. An Orchestrator can't simply transcode ads into the video and have this tied to viewership metrics. They would also be permanently embedded into the stream, including any clippings or recordings. Any views of the recorded or clipped content will definitely not be counted as a viewer from the ad providers' perspective. Since the Orchestrator only does transcoding of individual segments, this is the only method which can be implemented on the O level.
Dynamic ad insertion is a tight interplay between the client-side app and the media server serving the stream, so outside of the scope of the B/O/T nodes. It would be a fairly significant change to modify this workflow to have the O transcode this into the stream on request and then they still have to trust that ad sessions get created and handled correctly by the B
Then there are other technical issues like how to deal with the source track, which no player will be able to sync with the transcoded tracks unless the source track also gets transcoded. This would be costly and would not work for a low-latency protocol like WebRTC
Besides all of the technical hurdles to have ads be a monetisation model for the Orchestrator, it doesn't even makes sense to me. Why wouldn't the B just pay the transcoding fees and do the ads themselves? Do content creators ven want to use a platform which inserts ads on their content without them getting a cut?
Hi @stronk-dev , really thankful for your feedback. This is why we wanted these feed backs,to help my team best sharp our ideal, implementation flow and better understanding Livepeer infrastrue.
From the first water cooler chat we had with the community , my team have been discussing ,make neccessary changes to our approach on the proposal. Our ideal has evolved thanks to these feed backs from the community. These changes would have been seen here but we don't have edit right on this issue.
So just to clarify some items;
-
Some months prior , my team have researched and worked on samples demonstrating server side ad insertion(ssai) with viewership metric/ impression, clicks etc. tied into the process using googles PAL sdk. The ideal was to make the node in extra, similar to AWS media tailor, a third part service for ssai for a publisher.
-
Yes , majority of the implementation of DAI ,especially with Google's stack(which are leveraging for first implementation) are client side rich .Though we have opinion this can be done on server too (https://groups.google.com/g/ima-sdk/c/UnCD-XELTKo?pli=1). So has per community suggestion from the last cooler , we want to try out product ads placement @Titan-Node .
-
My team agrees with @rickstaa suggestion from the last water cooler, to make the implementation a middleware/plugin for broadcaster in order not to over complicate Livepeer's core codebase.
-
We think and agree this should only be a broadcaster side only implementation, in order to effect/address @leszko point.
My team is well capable and cant wait to bring ads to Livepeer. We will keep fining tuning our implementation.
My discord username is Eneche0343, i will definitely love to continue this discussion with you, please dm me.
@rickstaa hey again..Thank you ,really love your feed back.
Yes from the last cooler . You noted your preference for client side insertion . Though my team has samples for both CSAI and SSAI. We are advocating for SSAI because of the many advantages with will offer to Livepeer compare to CSAI.
-
Once the ads have been stitched into the video content, the video content and ads can then be used in an unlimited number of applications. Since Livepeer is an infrastructure for other platform to leverage . SSAI will offer a better flow for this reason, it will work fine regardless of the platform stack, mobile,web,cast,Roku ,tvos etc. No need for platforms to have different implementation for ad serving when using or leveraging Livepeer.
-
SSAI offers high ad-fill rates and can generate more impressions, with the average completion rate for SSAI ads.These are valuable ads on SSAI, as you know they will actually be seen by customers compared to CSAI where the ads can be blocked.
-
Varying bandwidth conditions allow SSAI to effortlessly deliver a smooth playback experience, improving the streaming quality. We want the stream to be less disruptive even with ads on video.
@leszko @stronk-dev @rickstaa @hansy
With client-side ad insertion, the video player typically switches between the main content and the advertisement. When this switch occurs, it is often preceded by a loading indicator. This is especially noticeable on mobile platforms, where there are strict video playback requirements and limited video playback capabilities.
There is a lot of video player logic involved in handling the steps involved in client-side ad insertion. While most video players today are able to correctly handle this, sometimes edge cases occur which result in playback stalls, failure to play ads, stream restarts, or a complete crash of the video player.
When video viewers are immersed in the content, they typically watch longer and more content. However, when any of these quality of service issues occur, a viewer’s immersiveness will be broken and there is a high chance that they will drop out early, negatively impacting ad completion rate and overall CPM.
When looking at client-side ad insertion, video-on-demand (VOD) content typically gets monetized through pre- or mid-roll advertisements. This is often more difficult to orchestrate in the case of live streamed content where ad breaks need to be scheduled at precise timings in order to ensure viewers do not miss out on anything important.
Today, most publishers try to resolve this problem by introducing a secondary communication channel between the video player and their ad server. As soon as an ad break is triggered in the live content, a signal is send over this communication channel towards all the viewers. This signal in turn will trigger the video player to initiate a CSAI workf low, loading and playing an ad instead of the main content.
This approach has a number of disadvantages. Firstly, it typically gets custom built, making it error prone and expensive to maintain. Secondly, this new communication channel is vulnerable to ad blockers. Third, this communication channel can introduce additional overhead and affect the overall scalability of the streaming solution.
Note: It will make less sense for Livepeer to embrace CSAI when major publishers and broadcaster are rapidly migrating from client-side to server-side ad insertion (SSAI)
I've never actually advocated for CSAI - my main concern is that the B/O/T nodes are too far removed from the content creator and viewers. The flow of a Livepeer powered media pipeline is:
Creator -> ingest node (-> optional stream duplication to other edge nodes) -> Viewer
Where the ingest node also creates transcoded renditions by requesting individual segment transcodes:
ingest node -> segment the input -> for each segment, request a B to transcode the segment -> B requests an O to transcode -> O requests T to transcde and return segment to the B -> media server downloads transcoded renditions from the B
The source rendition is available to viewers without delay and over additional protocols, WebRTC is currently the main protocol, which doesn't have a manifest to manipulate in the first place. So the scope of the grant has to be clearly defined, especially given the optimistic timelines
The only feasible way to implement SSAI is in the media server serving the stream to the viewer, which in the case of Catalyst would be in MistServer.
It's in the perfect position to stitch ads without transcoding them into the video. For Livestreams this would be unskippable, VOD would be a whole other can of worms.
It would also require a system to tie this to the content creator if they want to be able to get a cut of ad revenue, which only the ingest node has knowledge of
The B node could also do SSAI, but this would require a lot of additional work in how media servers interface with go-livepeer, since the B has no direct connection to the ingest and the media server needs to switch away from the per-segment upload/download workflow
So maybe it's a good idea for a revised proposal. I'm also interested in how this would tie into the long-term vision of turning the B/O/T stack into the ads provider a la Google's DAI API, cause that's a whole different approach and an immense scope of work to be done
Just following up on the conversation.
Here are my thoughts
-
I don't think full pages ads will work with SSAI. Most the reasons are already stated above. ie. Targeting, integration, necessity, etc. I think client side integration in a web3 style will end up being better suited anyway. Maybe economically driven? Instead of forcing someone to watch you just reward them with the ad spend (like Brave does). Full page ads are better suited for client side imo.
-
However, I do think product placement or video manipulation does work in this case. It actually requires work done by the O/T to insert the content, unlike ad stitching which can be done at a much earlier stage in the process such as at the broadcaster or streamer level.
I would be interested to see what the scope would be if the proposal only focused on video manipulation, maybe as a new job type? It would work nicely in line with what is already being considered with Stable Video Diffusion job types that Dob mentioned in the latest Open Network call.
Just following up on the conversation.
Here are my thoughts
- I don't think full pages ads will work with SSAI. Most the reasons are already stated above. ie. Targeting, integration, necessity, etc. I think client side integration in a web3 style will end up being better suited anyway. Maybe economically driven? Instead of forcing someone to watch you just reward them with the ad spend (like Brave does). Full page ads are better suited for client side imo.
- However, I do think product placement or video manipulation does work in this case. It actually requires work done by the O/T to insert the content, unlike ad stitching which can be done at a much earlier stage in the process such as at the broadcaster or streamer level.
I would be interested to see what the scope would be if the proposal only focused on video manipulation, maybe as a new job type? It would work nicely in line with what is already being considered with Stable Video Diffusion job types that Dob mentioned in the latest Open Network call.
Thank you, @livepeer-ssai, for the additional information. I remain neutral regarding ad-serving methods, be it client-side or server-side. My main interest lies beyond advertising specifics, as I'm not particularly inclined towards ads. Nonetheless, I acknowledge their potential advantages for the network. Due to my limited experience in advertising, I'll defer to your team and more seasoned experts for such decisions 😅.
The insights from @leszko, @stronk-dev, and @Titan-Node are invaluable and could significantly enhance your proposal 🚀.
In reviewing this proposal, my primary objective is to maintain the integrity and functionality of Livepeer's core codebase and pipeline. I view the service you propose as a potentially helpful tool for broadcasters to reduce transcoding costs 🚀. In the end, this will lead to more income for orchestrators, but I don't think it should be directly implemented on the orchestrator side. Therefore, I believe it's crucial to aim for an implementation that minimally disrupts the current orchestrator pipeline. The choice between client-side, server-side, or a hybrid approach for ad stitching or control is less critical from my perspective. Each approach has its own set of advantages and disadvantages. My primary concern is that whatever integration method is chosen should not compromise the stability and efficiency of the existing system.
This issue has been marked as stale with no activity. It will close in 7 days.