Feedback from DASH Industry Forum

[wilaw]

Feedback based on a review call 4/1/19 - present Will, Andy, Nicol, Zack.

1. Document should note that in multi-threaded environments (native players for example), there is the possibility of events being received in a different order to that in which they were dispatched. This difference may only be a millisecond or two, but it would be sufficient to confuse an analytics app following a rigid interpretation of the event sequence. It is suggested that analytics implementations maintain an play state model in order to correctly interpret event sequences.
2. For Nielson C-window stitched content, a note should be made that players must synthesize the appropriate events, as there will not be an obvious discontinuity in the content to signal such a transition.
3. Add a note to the table entry for playerResize event that this refers to the displayed area of the player and not the decoded are of the video.
4. Add a note to the table entry for EncodedVideoWidth/Height explaining that this refers to the width and height reported by the decoder, which may not match what was reported in the manifest. We would consider the decoder the source of truth. IN the event that the decoder infomation is not available within the player, then the reported video dimensions from the manifest may be used.

Reported by Will

[mlevine84]

1. WG agrees with the comment and will add "It is suggested that analytics implementations maintain a play state model in order to correctly interpret event sequences." in the appendix A.

2. WG needs further discussion with player working group members.

3. WG agrees with the comment. The playerResize definition has been updated.

4. WG agrees with the comment, the encodedVideoWidth/Height comment has been updated.

[mlevine84]

Item 1: Assign to Will

Item 2: Assign to Will with task to ask Turner about what they mean.

[njadia]

July 10, 2019 - Will Law will follow up on the action items.

[wilaw]

Item 1: added language to doc https://docs.google.com/document/d/1q6_8DPpidUHm3Pu2KXX588auAEEGaQUWO9IJHAoE17k/edit

[wilaw]

I followed up on item [2] and received the following response:

From: "Pope, Cooper" Cooper.Pope@turner.com Date: Friday, July 12, 2019 at 8:00 AM To: "Law, Will" wilaw@akamai.com Subject: Re: Question on c-window

[WL] "So if I understand it correctly, Nielsen C-3 windowed content is content, either live or VOD, that requires the baked-in ads be displayed and not replaced. These ad breaks should be signaled for analytics purposes even if they weren’t explicitly added through manifest manipulation."

[CP] Here's a snippet from another email I sent to someone else a while ago: Long ago, Nielsen only had to measure viewership during the live broadcast airing. When set-top DVRs became popular and many people stopped watching shows "live", Nielsen started giving ratings credit for all viewership within a 3-day window of the original airing – hence the name "Nielsen C-3 window". Technically it's a 75-hour window from the original airing time (3 days + 3 hours, to account for the Pacific time zone). There are rules and caveats, though. For example, the program/channel/broadcast-time information is carried in an audio watermark that spans program segments and national ads, so the original presentation must not be edited or modified (if you want credit). For OTT distribution to devices like AppleTV, FireTV, Chromecast, etc., it's possible to get credit through a TV that's attached to a Nielsen "people meter", so we often disable dynamic ad insertion and show the national ads if ratings credit is beneficial (i.e., for primetime shows, but not for re-runs of Friends). Nielsen has since introduced a digital ratings panel for OTT/mobile distribution – these programs are tracked with ID3 tags (rather than audio watermark) and allow DAI.

[WL] "My thinking here however is that the primary feed, containing the ads, would have been decorated with SCTE markers to indicate the start and end of the ads."

[CP] Correct.

[WL] "Any system that expected these ads to be tracked and counted by an analytics system would then package the content appropriately, by encoding key frames at the insertion points and adding discontinuity tags to the HLS playlists and period to the DASH manifests."

[CP] The stream is conditioned with an IDR (as you described) but for HLS the discontinuity tag is only required if you remove the linear ad segments and replace them with digital ads. Otherwise, the playlist contains one continuously coded stream (as you suggest below). The behavior in DASH might differ based on your method of segment description and/or how you plan to use the content downstream, right? (Question, not a statement.) That is, if you had a short segment on the CUE-IN/CUE-OUT, you might have to use a new period if an exact segment duration is required -- but for methods that allow you to signal a different segment duration, it would not necessarily require the new period, right? (Question, not a statement.) Are there any reasons to avoid multiple periods if they're not necessary? (We definitely avoid discontinuity tags if they're not necessary.) If so, I would only configure the packager to condition the stream with new periods on SCTE-35 boundaries if I was planning to repurpose the content for DAI later; otherwise, the packager could just output a single period. That's assuming you could still signal emsg/events without new periods, which I think is the case. </A little off-topic here> We can discuss at Mile High if you want. Just curious.

[WL] The “ad” content would in fact be a smooth continuation of the primary content, but the boundaries and signaling would still be created. Is this how it works in practice?" [CP] Yes, that's how it works for HLS (minus the discontinuity tags) -- the SCTE-35 would be present in the stream and content would be conditioned with IDRs.

Ahhhhh…Ok, after all of that discussion on SCTE-35, I think I remember more about this note – it makes more sense if you change "discon" to "manifest events/tags"; and "must" to "may need to": "For Nielson C-window stitched content, a note should be made that players must synthesize the appropriate events, as there will not be an obvious discontinuity in the content to signal such a transition"

On the call, I probably mentioned another method people use for signaling ads – it uses ID3 tags and/or emsg boxes (depending on your media container). Other than a short segment on the ad break boundary, there are no references in the playlist to indicate the presence of a break – for DASH, no new periods if you're not generating them. We only use it for beaconing linear ads in digital players for March Madness (i.e., no DAI or content replacement), but other people use them for DAI, as well. I'll bet that "synthesize the appropriate events" refers to a potential need for translating these into mpd event messages and/or triggering other player events that may expect a call flow driven by SCTE-35. I will have to think through these details again, but this is probably the area of concern for that note. I don't think my intention was to definitively say this would be needed – I think it would have intended to mean "possibly needed".

Does that sound familiar? I can elaborate more if needed. Hope it helps.

I'm sure you're busy, but let me know if you have a few minutes next week to catch up on Low-Latency stuff.

Best, Cooper

Workflow Item 2 is addressed in the last diagram in the doc.