Dash thumbnail parsing error if SegmentTemplate duration is in Float

ExoPlayer version: 2.16.1

It’s nice to see that ExoPlayer had released the thumbnail parsing in v2.16.0 against this issue https://github.com/google/ExoPlayer/issues/9500

But I am facing an issue where it is not able to parsing if the SegmentTemplate has the duration in float. I can see in the Unit test case of the commit in ExoPlayer, there also duration is integer not the float value. https://github.com/google/ExoPlayer/commit/585b0bddcc965e269ad9eb8810b6f8da2b062996

You can take this media which is open source in Dash-If player and here if you see Image AdaptationSet has duration in float and in this case, ExoPlayer demo app crashes.

{
   "name": "Dash Thumbnails",
   "uri": "https://dash.akamaized.net/akamai/bbb_30fps/bbb_with_4_tiles_thumbnails.mpd"
}

We already have a solution in our side where we do this parsing in our custom parser. https://github.com/kaltura/playkit-android/blob/9a50e17fd60fddd4452ee692f5d62efa6d738e5b/playkit/src/main/java/com/kaltura/android/exoplayer2/dashmanifestparser/CustomDashManifestParser.java#L1901 It will be nice to see this fix on ExoPlayer’s end.

Crash:

Playback error
      com.google.android.exoplayer2.ExoPlaybackException: Source error
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:628)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:604)
        at android.os.Handler.dispatchMessage(Handler.java:98)
        at android.os.Looper.loop(Looper.java:165)
        at android.os.HandlerThread.run(HandlerThread.java:61)
     Caused by: com.google.android.exoplayer2.upstream.Loader$UnexpectedLoaderException: Unexpected NumberFormatException: For input string: "158.642"
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:430)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
        at java.lang.Thread.run(Thread.java:760)
     Caused by: java.lang.NumberFormatException: For input string: "158.642"
        at java.lang.Long.parseLong(Long.java:443)
        at java.lang.Long.parseLong(Long.java:485)
        at com.google.android.exoplayer2.source.dash.manifest.DashManifestParser.parseLong(DashManifestParser.java:1825)
        at com.google.android.exoplayer2.source.dash.manifest.DashManifestParser.parseSegmentTemplate(DashManifestParser.java:993)
        at com.google.android.exoplayer2.source.dash.manifest.DashManifestParser.parseAdaptationSet(DashManifestParser.java:476)
        at com.google.android.exoplayer2.source.dash.manifest.DashManifestParser.parsePeriod(DashManifestParser.java:308)
        at com.google.android.exoplayer2.source.dash.manifest.DashManifestParser.parseMediaPresentationDescription(DashManifestParser.java:157)
        at com.google.android.exoplayer2.source.dash.manifest.DashManifestParser.parse(DashManifestParser.java:106)
        at com.google.android.exoplayer2.source.dash.manifest.DashManifestParser.parse(DashManifestParser.java:62)
        at com.google.android.exoplayer2.upstream.ParsingLoadable.load(ParsingLoadable.java:176)
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:409)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607) 
        at java.lang.Thread.run(Thread.java:760) 

[ojw28]

Without a compelling reason to need to fix this, I’m not convinced that we should do so. Replacing an obvious failure mode (e.g., a stack trace that makes it clear exactly what the issue is) with a more obscure one (e.g., playback works but silently discards the malformed part of the manifest) is likely to lead to confusion in the future as the problem that occurs will be more subtle.

We don’t have any evidence to suggest that streaming providers have deployed content that’s malformed in this way into production (currently all we have is one piece of demo content). And even if they have, we don’t have evidence that (a) it’s hard for them to fix their content, which they should do anyway to ensure compatibility with players, and (b) it’s hard for them to workaround the problem they’ve created for themselves client-side (it actually appears to be not too difficult). So I don’t think we have a compelling reason.

[GouravSna]

Hi @ojw28 , As this crash is only for the image tracks, we suggest that Exoplayer should at least play the media except the images. For Images, you can log the warning.