Occasional Conformance Violation: INVALID_DVR_WINDOW errors seen

[markriley9999]

conformance-violation-161125 - Copy.mpd.txt

• [Some issues raised, but appear to be benign, unrelated to this issue] The MPD passes the DASH-IF Conformance Tool on https://conformance.dashif.org/
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream
• The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• [occurs in v4.7.4 ref player] The issue occurs in the latest reference client on http://reference.dashif.org/dash.js/ and not just on my page

• Link to playable MPD file:
• Dash.js version: v4.7.4
• Browser name/version: multiple (edge, chrome, vewd etc)
• OS name/version:

I see occasional Conformance Violation: INVALID_DVR_WINDOW errors (say every hour or so), affecting multiple devices at the same point in time.

I have captured an example mpd, at the point of failure, here.

At this point in time there are 2 periods:

The tail end of the first period - as you can see it's now very short, with only a single short duration segment remaining.
I think this is pertinent as this the point at which I see repeatedly see the failure happen.

    <Period duration="PT0.681S"
            id="881659269"
            start="PT16458H42M19.319S">
...
                <SegmentTimeline>
                    <S d="34000"
                       t="88165926966000"/>
                </SegmentTimeline>
...

And the remaining period (containing the live edge):
This period is ~15 mins long,

    <Period id="881659270"
            start="PT16458H42M20S">
...
                <SegmentTimeline>
                    <S d="200000"
                       t="88165927000000"/>
                    <S d="100000"
                       r="447"
                       t="88165927200000"/>
                </SegmentTimeline>
...

The issue seems to be transient, in that it shortly recovers (however, unfortunately our player catches this error and stops playback!)

I've also noticed that setting 'fallbackToSegmentTimeline: false' allows that stream to play continuously without issues (ie if there really is an issue in the mpd it would appear to be benign).

At the point of the INVALID_DVR_WINDOW error being triggered, ie via:

        if (settings.get().streaming.timeShiftBuffer.fallbackToSegmentTimeline) {
            const timelineRefData = _calcTimeShiftBufferWindowForDynamicTimelineManifest(streams);
            if (timelineRefData.range.end < range.start) {
                eventBus.trigger(MediaPlayerEvents.CONFORMANCE_VIOLATION, {
                    level: ConformanceViolationConstants.LEVELS.WARNING,
                    event: ConformanceViolationConstants.EVENTS.INVALID_DVR_WINDOW
                });
                _adjustTimelineAnchorAvailabilityOffset(timelineRefData.now, timelineRefData.range);
                return timelineRefData.range;
            }
        }

Looking at timelineRefData, i see:

         "timelineRefData": {
            "range": {
               "start": "59251339.319000006",
               "end": "59251339.99900007"
            },
            "now": "59252242.6215"
         }

The calculated duration is (only!) 0.680000064s - where timeShiftBufferDepth="PT15M1S"
So, it would appear that in this case, only the 1st period is taken into account.

Checking the same stream at a later point, say 10s later, the timelineRefData calc then returns a range covering all the periods.

So there appears to be a transient issue - where for some reason, the manifest derived range calcs are occasionally incorrect (but corrects itself shortly after).

I've looked at the mpd, and I cannot see anything obvious - but as I mentioned earlier, this consistently happens when there are 2 periods, where the first period is very short, ie <1s....

Any help would be very much appreciated!

[dsilhavy]

@markriley9999

• Do you see the same behavior in the latest nightly build: https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html
• Can you share your content with me?
• It might be that the upcoming period is not initialized yet and therefor not taken into account when doing this conformance check. However, I wouldn't treat the CONFORMANCE_VIOLATION events as a critical error. This is meant to be a supporting message in case something goes wrong with the playback. dash.js itself does not react to a CONFORMANCE_VIOLATION event and playback should continue.

[markriley9999]

Hi
thanks for getting back to me. wrt your questions:

Do you see the same behavior in the latest nightly build: https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html

This is a bit tricky, as the dash.js player is integrated into the 'video window of an hbbtv opapp'. we are playing back these streams on UK 'Freely' TV/STB devices. Also because it can take many hours to reproduce and only certain devices have a tendency to catch this issue (what i see is multiple devices, but not all, failing at the same time on a period boundary) - so i need some way to catch and log failures (which the opapp has). I'll try it using my standalone test player.

Can you share your content with me?

Yes, i'll see what i can do (i'll have to dm you directly the details as these are commercial streams). I forgot to mention that this is not content provider / packager specific - the common thread is that the issue is seen at the end of a dash period on multiple (all?) of the streams on the platform.

It might be that the upcoming period is not initialized yet and therefor not taken into account when doing this conformance check.

That's an interesting theory - this issue appears to be a race-condition affecting only certain devices, i'm wondering if this is related to the device's incumbent processing power or perhaps some devices are playing back a little closer to the live-edge (or something else!)

However, I wouldn't treat the CONFORMANCE_VIOLATION events as a critical error. This is meant to be a supporting message in case something goes wrong with the playback. dash.js itself does not react to a CONFORMANCE_VIOLATION event and playback should continue.

Ok, that's worth knowing, thanks.
However, I think that this specific CONFORMANCE_VIOLATION check is not benign, as it returns what it believes is the only available time window that the player can use - so forces playback within this vanishingly small first period, which causes a playback stall.
For now i'm setting 'fallbackToSegmentTimeline: false' - to disable this error checking (and playback correction), and playback stability appears to be very much improved across-the-board.

[dsilhavy]

Hi thanks for getting back to me. wrt your questions:

Do you see the same behavior in the latest nightly build: https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html

This is a bit tricky, as the dash.js player is integrated into the 'video window of an hbbtv opapp'. we are playing back these streams on UK 'Freely' TV/STB devices. Also because it can take many hours to reproduce and only certain devices have a tendency to catch this issue (what i see is multiple devices, but not all, failing at the same time on a period boundary) - so i need some way to catch and log failures (which the opapp has). I'll try it using my standalone test player.

Can you share your content with me?

Yes, i'll see what i can do (i'll have to dm you directly the details as these are commercial streams). I forgot to mention that this is not content provider / packager specific - the common thread is that the issue is seen at the end of a dash period on multiple (all?) of the streams on the platform.

It might be that the upcoming period is not initialized yet and therefor not taken into account when doing this conformance check.

That's an interesting theory - this issue appears to be a race-condition affecting only certain devices, i'm wondering if this is related to the device's incumbent processing power or perhaps some devices are playing back a little closer to the live-edge (or something else!)

However, I wouldn't treat the CONFORMANCE_VIOLATION events as a critical error. This is meant to be a supporting message in case something goes wrong with the playback. dash.js itself does not react to a CONFORMANCE_VIOLATION event and playback should continue.

Ok, that's worth knowing, thanks. However, I think that this specific CONFORMANCE_VIOLATION check is not benign, as it returns what it believes is the only available time window that the player can use - so forces playback within this vanishingly small first period, which causes a playback stall. For now i'm setting 'fallbackToSegmentTimeline: false' - to disable this error checking (and playback correction), and playback stability appears to be very much improved across-the-board.

Thanks for the insights. Indeed, if you disable fallbackToSegmentTimeline then we do not take the SegmentTimeline entries into account for the DVR window verification. We just added fallbackToSegmentTimeline as an additional mechanism to overcome MPD timing issues.

What would also be great is if you can share a snapshot of the MPD at the time when the violation occurs.

[markriley9999]

Hi

i attached it at the start of this ticket:
https://github.com/user-attachments/files/23584031/conformance-violation-161125.-.Copy.mpd.txt

can you see it? Or did i do something wrong (i had to change the .mpd to .txt inorder to attach it)?
fyi, i have more examples, if that helps. :)

Mark