Maybe ask your ad provider? Without a live streaming implementation of your content you would need to break your video into sections and then use repeated preroll calls for each section in the desired allotment - otherwise users could fast forward and resume playback after the ad points without being subjected to the ads.
Injecting ads into VOD content is doable, but not the best user experience because of the multiple buffer screens that will be displayed.
Basically, you want to watch the isPlaybackPosition event to decide when to do the injection. You do have to account for cases like the user FF'ing past an ad point. There's also the case where a user watches an ad, then RW's to a point before it, you have to decide whether to make them watch the ad break a second time.
When you hit a point where you want to inject an ad, you need to save the position and close the video screen. Then play the ad using the same method as the preroll. Then resume the content where you left off by setting its playStart attribute.
If you are planning to target your channel only at newer boxes, there is a new event (not sure off hand if it was in 5.1 or 5.2) called isResumeRequest that can help reduce the number of buffer screens in the FF/RW scenarios.
"agmark" wrote: Chris...is the isResumeRequest documented? Not finding it.
I don't see it either. It's new, but I'm sure it will get in there soon. Using it is pretty basic. It's off by default, to enable it do this:
Then, every time the screen is about to exit trick play mode, you will get an isResumeRequest event. GetIndex() will return a unique ID for this resume request. GetData() will return the position where the video is about to resume.
At this point you can do whatever stuff you need to, like injecting an ad.
In order for the screen to continue normally after an isResumeRequest event, you must do this: