§9.4 - Splicing of a WAVE Presentation - Stimulus

[rcottingham]

The stimulus (§9.4.4) for "§9.4 Splicing of WAVE Program with Baseline Constraints" test seems to be incorrect (maybe a copy/paste issue) - we would expect something similar to the stimulus for single track playback i.e. as per §8.8.4 (but detailing for both audio and video).

[gitwjr]

@haudiobe to review "§9.4 Splicing of WAVE Program with Baseline Constraints" and correct/add detail on how audio is handled per comments above.

[rcottingham]

§9.4 has been re-written in v1.48 of the spec - it makes good sense, but raises a few issues/questions:

• Test parameters

  An aligned media time Tsplice in the first Audio and Video Switching Set that con-incide with a Fragment Boundary and is instructed for playback.

Tsplice is a new new parameter (used instead of playout): both TR and OF will need to be changed - we propose to maintain the "playout" parameter rather than introduce a new one

• Test content

  In the first switching set pair, there exists at least one media time greater than 0, for which the Audio and Video Switching Set co-incides with a Fragment Boundary

Current combinations of existing video and audio don’t meet this requirement. Specific video or audio or both to be regenerated to align fragment boundaries (matching video to existing audio may be easier?)

• Observations

  At the splice point 1, when the second presentation starts, no gap is observed in playback At the splice point 2, when there is a return to the first presentation, no gap is observed in playback.

Need to define "no gap" tolerance (0ms will be difficult to measure) High impact on the OF as this is a new type of observation logic

In summary - it will not be possible to implement these new observations in the near term (new obs logic, dependency on TR, content changes...)

[haudiobe]

add a tolerance aligned with other clauses.

[haudiobe]

added: 3) At the splice point 1, when the second presentation starts, the presentation is observed continuous without gap in playback within the tolerance of +/- (2/framerate + 20ms)

[yanj-github]

added: 3) At the splice point 1, when the second presentation starts, the presentation is observed continuous without gap in playback within the tolerance of +/- (2/framerate + 20ms)

I think it should not allow minus (-), second presentation should not be presented before the 1st presentation finished at splice point 1. At the splice point 1, when the second presentation starts, the presentation is observed continuous without gap in playback within the tolerance of 2s/framerate + 20ms

[gitwjr]

@rcottingham will review.

[rcottingham]

Yan's last comment above not yet implemented in spec v1.53 - §9.4.5.1, point 3) to be updated to

At the splice point 1, when the second presentation starts, the presentation is observed continuous without gap in playback within the tolerance of 2s/framerate + 20ms

[gitwjr]

11-21-23: Need to make a change to handle the minus second presentation to close. @yanj-github to double check the spec.

[yanj-github]

9.4.5.1 3) At splice point 1, when the second presentation starts, the presentation is observed continuous without gap in playback within the tolerance of +/- (2/framerate + 20ms). Issue: gap cannot be (-)

Please change to: 3) At splice point 1, when the second presentation starts, the presentation is observed continuous without gap in playback within the tolerance of (2/framerate + 20ms).

[yanj-github]

Previous issues that we mentioned https://github.com/cta-wave/device-playback-task-force/issues/111#issuecomment-1631177188 still presents, I am highlighting them again as follows:

• Test parameters

An aligned media time Tsplice in the first Audio and Video Switching Set that con-incide with a Fragment Boundary and is instructed for playback.

Tsplice is a new new parameter (used instead of playout): both TR and OF will need to be changed - we propose to maintain the "playout" parameter rather than introduce a new one, "playout" parameter for video and audio play should match video. Did we get agreement on this one please?

• No right Test content available

In the first switching set pair, there exists at least one media time greater than 0, for which the Audio and Video Switching Set co-incides with a Fragment Boundary

Current combinations of existing video and audio don’t meet this requirement. Specific video or audio or both to be regenerated to align fragment boundaries (matching video to existing audio may be easier?)

• Observations

At the splice point 1, when the second presentation starts, no gap is observed in playback At the splice point 2, when there is a return to the first presentation, no gap is observed in playback.

Need to define "no gap" tolerance (0ms will be difficult to measure), we need to agree with tolerances. High impact on the OF as this is a new type of observation logic, not yet available on OF

@gitwjr, @jpiesing and @louaybassbouss I think 9.4 test should be marked as "non-validated"?

[rcottingham]

Hi @haudiobe - please can you review Yan's last comment; we can discuss in the next DPCTF call on 14th Feb.

cc @jpiesing @louaybassbouss

[haudiobe]

All, as I read this is pointing to a possible errata in the DPC spec. However, I would like to discuss why no gap is not possible. I understand that no gap may be hard to quantify, but from a first approach it seems to be correct. With proper conditioning of the content you can use the same media pipeline and playback without gaps. @dsilhavy may be able to confirm as well

[jpiesing]

Previous issues that we mentioned #111 (comment) still presents, I am highlighting them again as follows:

* Test parameters

An aligned media time Tsplice in the first Audio and Video Switching Set that con-incide with a Fragment Boundary and is instructed for playback.

Tsplice is a new new parameter (used instead of playout): both TR and OF will need to be changed - we propose to maintain the "playout" parameter rather than introduce a new one, "playout" parameter for video and audio play should match video. Did we get agreement on this one please?

I think Tsplice is still needed even if you re-introduce playout[]. Also since video and audio fragments may have different durations, aren't two playout's needed, one for video and one for audio? (This would not be needed if only using Tsplice).

Would it not be something like this ...

For video playout, playout_video[1] to playout [index of fragment ending at Tsplice] = 1, playout[index of fragment starting at Tsplice] to playout[index of final fragment] = 2. And the same for audio except the indexes would be different to reflect different fragment lengths.

* No right Test content available

In the first switching set pair, there exists at least one media time greater than 0, for which the Audio and Video Switching Set co-incides with a Fragment Boundary

Current combinations of existing video and audio don’t meet this requirement. Specific video or audio or both to be regenerated to align fragment boundaries (matching video to existing audio may be easier?)

I've created a new github issue in test content generation.

* Observations

At the splice point 1, when the second presentation starts, no gap is observed in playback At the splice point 2, when there is a return to the first presentation, no gap is observed in playback.

Need to define "no gap" tolerance (0ms will be difficult to measure), we need to agree with tolerances. High impact on the OF as this is a new type of observation logic, not yet available on OF

Here is a suggestion.

• For video, no gap means a QR code is detected on every frame. This isn't perfect and relies on advanced picture processing being disabled on the TV otherwise frames of video may bleed into a black frame.
• For audio, no gap means no silence but I have no idea if that's detectable.

@gitwjr, @jpiesing and @louaybassbouss I think 9.4 test should be marked as "non-validated"?

Yes

[haudiobe]

DPCTF Call on 2024/02/28

• For video, no black frames or any reset is expected as the splicing is transparent to downstream display management. It is a pre-decoder operation. Key issue is the proper usage and implementation of the timeOffset on MSE together with a possibly "seamless" switch as already defined for Switching Set testing.
• For audio, conditioning the content may be the main challenge. We need to see if we have such content available. We can check more details on the content requirements.

@haudiobe based in discussion, revisit the test description and provide proposed updates.

Based on this we check if we have appropriate content and if any changes to observation framework needs to be done.