Mp4Extractor should interpret atomSize==0 as "extends to end"

[itspbj]

Issue description

I'm attempting to play a video file thats from the Xbox API. Specifically, the first video in this list: https://streamable.com/search/xbox?query=TechGuruGJ titled "Forza Horizon 3" plays on the web but doesn't seem to work in ExoPlayer.

I've looked through other issues, and it seems like there may be some sort of fix listed here: #1287. The "Ignore stream defined index if manifest defines one." commit sounds like I could add something to my application manifest to fix the issue.

I do not own the content which I am trying to play, so while it sounds like the format may be invalid, I am unable to change the source. Is there anything I can do to forcefully play the video using ExoPlayer?

Reproduction steps

1. Navigate to https://streamable.com/search/xbox?query=TechGuruGJ
2. Inspect element using Chrome, and pull the latest video url from video titled "Forza Horizon 3".
3. Plug in URL into ExoPlayer.

The video URLs change regularly for any video which is why I can't give you one explicitly because I am not sure if it will still be a valid URL by the time you use it.

Link to test content

1. You can try using downloading: https://play.google.com/store/apps/details?id=com.swerve.clipz&hl=en.
2. Create an account through Twitch.
3. Navigate to Clips Tab > Xbox Tab. Enter gamertag TechGuruGJ.
4. Click the first video in the list. Fails with 416 error code.

Version of ExoPlayer being used

r2.3.1

Device(s) and version(s) of Android being used

Nexus 6P API 23

A full bug report captured from the device

temp.txt

[ojw28]

This is actually a bug in our MP4 extractor, where we don't handle atomSize==0 correctly. I'm assuming this is a rarely used feature in the MP4 spec, seeing as we haven't seen this before.

[itspbj]

Anything I can change to avoid it or does it just require a bug fix?

[ojw28]

I think there are actually two stray zero bytes at the end of the media, although since they're factored into sizes specified elsewhere in the media just clipping the file by two bytes doesn't fix the problem. If you're generating this content yourself then you could investigate what the last two bytes of the file actually are, and why they're being added. The bug fix we'll be making fixes the problem by treating these two bytes as an atom with id 0 that extends to the end of the file, however this doesn't explain why those two bytes are there in the first place.

Short of changing the media, you'll have to wait for a bug fix. We'll push one to dev-v2 this week.

[itspbj]

Unfortunately I don't own the content so I won't be able to fix it. Thanks for adding the fix! Looking forward to the update.

[ojw28]

Fixed in dev-v2.