Playback fails due to integer overflow using large SegmentTemplate startNumber parameters

[Mr-Clam]

We've encountered a playback failure due to the wrong size variable used for the startNumber attribute/$Number parameters in templates, per the following example from an MPD where startNumber="1480044110":

        <AdaptationSet mimeType="video/mp4" codecs="hvc1.1.2.L180.b0" lang="eng">
            <Representation id="0" bandwidth="15360000" width="3840" height="2160" startWithSAP="1">
                <SegmentTemplate timescale="10000000" media="15000/file_video_15000kbps-$Number$.mp4" startNumber="1480044110" initialization="15000/file_video_15000kbps.init">
                    <SegmentTimeline>
                        <S d="60060000" r="-1"/>
                    </SegmentTimeline>
                </SegmentTemplate>
            </Representation>
        </AdaptationSet>

You might ask why we use such large numbers: we set startNumber to current timestamps according to Akamai qualification recommendations, which state:

Segment numbers must not repeat when a live encoder restarts. This can be
achieved when the segment numbers are derived from current epoch time. This
results in always increasing segment numbers and prevents overwriting data in
the storage system.

We worked around this by subtracting the UNIX time for 1/1/16, but I suppose there could be other encoders/packagers using the literal definition from Akamai.

A Java 32 bit integer should be sufficient to hold epoch time, but not if you add the two values together and divide by 2 to get the midpoint as the Exoplayer code does. We tried a quick hack that simply used longs to prove it worked, but better would be to subtract the values and divide by 2 then add to the lower value. Then there is not chance of an overflow even using integers. I.e. you should be able to fix this easily (we were looking at a fork of your code from over a year ago and I'm not sure where the logic is now, but you can see the problem in this older version on this line of code: https://github.com/google/ExoPlayer/blob/release-v1/library/src/main/java/com/google/android/exoplayer/dash/mpd/SegmentBase.java#L147).

[ojw28]

I'm not sure that's exactly what Akamai mean ("derived from" != "equal to"). What you've done sounds sensible (it seems preferable to keep doing that to ensure you don't run into similar issues with other players). We'll change the logic in ExoPlayer to handle this case also. Thanks.