Playback freeze at the end of the first period on multi-period Dash streams

[danielgliga3ss]

Based on my debugging analysis the freeze happens at the end of the first period.
I have observed that when BufferInfo->presentationTimeUs reach 1000008704000 value (first period duration="PT8.72S") android.media.MediaCodec#dequeueOutputBuffer() returns -1 for an indefinite period of time and the playback gets stuck at this position.
com/google/android/exoplayer2/mediacodec/SynchronousMediaCodecAdapter.java:122

screenshot with my logs:

Logs I have added:

With the previous Exoplayer version we have used 2.12.1 this behavior is different and there is no freeze, dequeueOutputBuffer() returns -1 for a short period, and then presentationTimeUs jumps to 8736000.

Played manifest
manifest (7).txt

Is this caused by an Exoplayer or MediaCodec issue? Is there any workaround we can do to bypass the problem?

Logs:
logcat.txt
bugreport-SEI700TE-RTT0.210618.003-2022-02-11-15-36-12.zip

Stream (Note: Stream URLs will expire after a while or there might be some geo-blocking issues):
"uri": "http://vcdn.tv.comhem.se/cu/dash/cenc/HD/50fps/high/2ch/2nd/76806/1644213600/1644217500/manifest"
"drm_scheme": "widevine"
"drm_license_uri": "https://api-staging.tv.comhem.se/license/widevine/Lcb5nmz7ZmV20zplmkPXUt8ieyXIcMBSO58OxfZ9e__hPNcfaeMHYdmqeHEG0Zrt-3CdOmpOCIQvBeJQDGoxK-kHAx3ucpL85XFK2R93_UawFXr-3ezVbntIa1aEHVUsv6CG3x-4cpYKZK601ryHgtjyOabqzMoIoKkAgatFqdQHlbCF4WWs_YbEzuI5mCOV"

ExoPlayer version: 2.16.1
Android device: Technicolor UZX8020CHM (https://sites.google.com/view/droid-tv/pay-tv-provider/com-hem-tv-hub) -> Android 9,
SEI Robotics SEI700TE (https://www.androidtv-guide.com/pay-tv-provider/tele2-tv-hub-mini/) -> Android 11

[ojw28]

The issue occurs because the manifest contains incorrect event presentation timestamps. For example, the first period in your manifest contains this:

    <Period start="PT0S" id="p_5_411053387" duration="PT8.72S">
        <EventStream schemeIdUri="urn:scte:scte35:2014:xml+bin" timescale="180000">
            <Event id="1073947003" presentationTime="295958438769600" duration="10800000">
                <scte35:Signal>
                    <scte35:Binary>/DAlAAAAAs0wAP/wFAVAAyF7f+/+olw04P4AUmXAEiIAAAAA/WqzXg==</scte35:Binary>
                </scte35:Signal>
            </Event>
        </EventStream>

As per the DASH specification Event @presentationTime values are relative to the start of their containing period. This means the event occurs at 295958438769600/180000 = 1644213548s after the start of the period, however the period is only 8.72s long, so this is clearly incorrect. It looks like @presentationTime is being incorrectly set to be relative to the epoch, rather than to the start of the period.

This is a problem for ExoPlayer, because the player is waiting until it's finished playing the period before advancing to the next one. This includes outputting this event at its specified time, and so the player is stuck waiting to do that.

We should change ExoPlayer to discard events that are beyond the end of their containing period. We already clip audio and video at the period end point, which is in line with DASH-IF interoperability recommendations. The only reason we haven't done this for events defined in the manifest is because there's no legitimate reason for a manifest to ever include such events in the first place (where-as there are valid technical reasons why the final audio/video segments may contain media beyond the end point of the period).

Marking as bad media, but also as a bug, since we'll implement clipping of such events. I suggest that you also fix your manifests, particularly if it's important to you that the events are output at the correct times.