Our current implementation of VMAP support is a bit static, we'd create a session on the stitcher and at that point do everything in 1 take:
Fetch VMAP.
Fetch all corresponding VAST files, and start a transcode job once they're not yet available.
Build up interstitials and insert them in the playlist.
We could split this logic, which would make the implementation less static. We'd probably be able to do something like this:
We create a session that includes the VMAP.
When we approach master.m3u8 in a session, we fetch the VMAP and keep a representation of that in memory (or redis).
When we approach playlist.m3u8, we have a VMAP representation in memory and we can use that to insert the proper DATERANGE tags. We no longer rely on timeOffset but keep a map of each [START-DATE, AdBreak] (stripped down version of a vmap:AdBreak in the VMAP), this'll be our own representation of what we mean by AdBreak.
We don't approach any of the VAST correlated to the VMAP yet, this'll happen later.
The idea is that for each given START-DATE, we can access the AdBreak data originally from the VMAP.
When we approach asset-list.json?dateRange=[START-DATE], we lookup whether we need to fetch one or more VAST files.
When the MediaFile is available as an HLS playlist, we'll send it to transcode and package and continue.
When, for a VAST, we do have an HLS playlist, we include it in the ASSETS response.
The trick is to have a map between a pairs of START-DATE + AdBreak. It doesn't really matter where these come from (as a first implementation, we derive this from a VMAP), aslong as we can say "for this given startDate, we have this adBreak to serve out", it'll map really well on dynamic playlists (those missing EXT-X-ENDLIST).
As a final remark, there's probably some caching to do to ensure we do not approach an ad server multiple times for a given session id, as they'll return with a different response (ad servers cap results, see the correlator param on Google IMA's ad server). LRU would be nice for this, when a playlist or asset-list is no longer consumed, at some point it'll be removed from memory this way.
Our current implementation of VMAP support is a bit static, we'd create a session on the stitcher and at that point do everything in 1 take:
We could split this logic, which would make the implementation less static. We'd probably be able to do something like this:
master.m3u8in a session, we fetch the VMAP and keep a representation of that in memory (or redis).playlist.m3u8, we have a VMAP representation in memory and we can use that to insert the properDATERANGEtags. We no longer rely ontimeOffsetbut keep a map of each[START-DATE, AdBreak](stripped down version of a vmap:AdBreak in the VMAP), this'll be our own representation of what we mean by AdBreak.START-DATE, we can access the AdBreak data originally from the VMAP.asset-list.json?dateRange=[START-DATE], we lookup whether we need to fetch one or more VAST files.MediaFileis available as an HLS playlist, we'll send it to transcode and package and continue.ASSETSresponse.The trick is to have a map between a pairs of
START-DATE+AdBreak. It doesn't really matter where these come from (as a first implementation, we derive this from a VMAP), aslong as we can say "for this given startDate, we have this adBreak to serve out", it'll map really well on dynamic playlists (those missingEXT-X-ENDLIST).As a final remark, there's probably some caching to do to ensure we do not approach an ad server multiple times for a given session id, as they'll return with a different response (ad servers cap results, see the correlator param on Google IMA's ad server). LRU would be nice for this, when a playlist or asset-list is no longer consumed, at some point it'll be removed from memory this way.