Unacceptably large manifest size for long DVR windows with many ad avails.

[wilaw]

[Filed on behalf of Janusz Szalapata] We are working on ads and have hit a bit of an issue with the manifest size. When we add ads periods to the manifest – the size of the manifest grows more than 10x which then poses an issue for players. Do you know if there are any plans within DASH community to implement a solution similar in terms of benefits to what Roger proposed with Playlist Delta (or what allows for in MSS)? We are trying to mitigate the issue by limiting the amount of data within periods but that is really a short term solution for now.

Each ad break currently weights circa 23kb and with optimisations [use SegmentTemplater/$Number, and/or SegmentTimeline with 'r'] we can go to 5kb per ad break. However that still limits DVR length and number of ad breaks (due to 200kb hard stop limit as mentioned earlier). We currently have DVR=300mins and with above calculations: we could fit 3 ad breaks x 8 personalised ads into 160KB assuming 30 mins between ad breaks, DVR window could safely be ~90minutes (possibly as high as ~120 minutes) 10KB + (8 x 5KB) + 10KB + (8 x 5KB) + 10KB + (8 x 5KB) + 10KB = 160KB

Above setup would work in theory for football for example but not for sports with more commercial opportunities. Long DVR is also a feature that users have asked for. The key question is then: how can we keep long DVR window with ads and stay under 200kb manifest size limit?

[wilaw]

DASh IOP group is looking at 3 potential solutions

• Patches
• XLINK for older periods
• Event stream that indicates that you can have a period at that point.

[haudiobe]

(AdIn 19/11/22) DAZN creates manifest and gives it to Google for Ad Insertion.

We looked at manifest and there are obvious optimization opportunities. But still, we would like to have a clear set of recommendations/requirements for interop.

• Patches: would allow to describe back buffer once, but live once. Ad Insertion less simplified. We need to think through how Ad Insertion is combined with Patches.
  • (Zach) develop some slides for f2f meeting
• Xlink: only in the timeshift you would resolve. May work, but not used today.
  • (Thomas) document how it may be used.
• Event stream: see slides files.groupspaces.com/dashif/files/2346418/1Hky8HOiVy42u8_IgpqO/Splice+Point+Signaling.pptx
  • We check if existing SCTE-35/SCTE-67/SCTE-214 is good enough to provide same functionality. SCTE-35 has message. Signals avail, but this not signal conditioning. (Peter, Zach)
  • Only signaling from live content server to ad insertion proxy - terminate there
  • we need such signaling anyways for avoiding to provide Period for every splice point

[technogeek00]

SCTE links for the group:

• SCTE-35 2019r1 - Digital Program Insertion Cueing Message
• SCTE-214-* - MPEG DASH for IP-Based Cable Services
  • Part 1 (SCTE-214-1 2015) - MPD Constraints and Extensions
  • Part 2 (SCTE-214-4 2018) - SCTE Common Intermediate Format Manifest for ATS Streams
  • Note there are parts 2/3 but they do not apply to our conversation.
• SCTE-67 2017 - Recommended Practice for Digital Program Insertion for Cable

[technogeek00]

Would we recommend pushing this into the second iteration of this document as both Patches and XLink are being considered for the later SGAI architecture? Additionally I think the MPEG ad-hoc's work will likely provide better definition on direction here that we should follow in the IOP

[RufaelDev]

I still have some support for thomases proposal on event stream, as it would allow the multi-period to be created based on events carried in the manifest, this could effictively reduce the size of the manifest a lot. To not hold up the problem more for ad insertion CR, perhaps move this to Multi-Period CR.

[haudiobe]

DASH-IF IOP 2021/05/14:

• MPD Event is defined that says that you can add a Period at this point. m55280_Period Event.zip