Can not play the mp4 video (Mp4Extractor can't parse FullBox meta atoms)

[gemiren]

Using the latest v2.9.6. Trying to play this video (https://wdrmedien-a.akamaihd.net/medp/podcast/weltweit/fsk0/188/1884161/quarks_2019-03-26_sommeroderwinterzeitwarumunszeitumstellungensostressen_wdr.mp4) gives this error:

E/LoadTask: Unexpected exception handling load completed
    java.lang.NullPointerException
        at com.google.android.exoplayer2.util.Assertions.checkNotNull(Assertions.java:111)
        at com.google.android.exoplayer2.source.ExtractorMediaPeriod.onLoadCompleted(ExtractorMediaPeriod.java:504)
        at com.google.android.exoplayer2.source.ExtractorMediaPeriod.onLoadCompleted(ExtractorMediaPeriod.java:57)
        at com.google.android.exoplayer2.upstream.Loader$LoadTask.handleMessage(Loader.java:450)
        at android.os.Handler.dispatchMessage(Handler.java:106)
        at android.os.Looper.loop(Looper.java:193)
        at android.os.HandlerThread.run(HandlerThread.java:65)

The same video plays well in VLC player.

[marcbaechinger]

Thanks for reporting.

As far as I see, there are 4 extra zero bytes right after the meta atom header. These 4 bytes are then interpreted as the length of the following hdlr atom. A size of zero would indicate that the atom has a length until the end of the file.

6d 65 6c 72 // ''meta'
00 00 00 00 // <--- unexpected zeros interpreted as size of the next atom
00 00 00 21 // size=33
68 64 6c 72 // 'hdlr'

Do you have several of these files or is this a single case? If you are having multiple of these files do you know how these have been created?

[gemiren]

Thanks for looking into the problem. Yes, I agree the file isn't encoded correctly. However, I don't know how the file is created. Actually this encoding issue currently presents in almost all the video podcasts produced by the WDR (the largest media company in Germany). So this is not just a couple of files affected.

Regarding the wrong size info itself, not sure how VLC handles that but the fact that VLC can play this file without any issue indicates we probably can ignore that in ExoPlayer. Currently it will crash the ExoPlayer is really ugly.

[marcbaechinger]

Thanks, that makes sense. It could be avoided while parsing by making sure that a subatom does not have a size bigger than the parent atom size. This would work for the given case of the meta atom. I guess this could be the way how VLC and other players are doing it.

We will discuss internally how to proceed.

<-- start personal opinion: this does not express any other opinion than mine. :) --

Given no video player would support that content you would not have this problem now, because you could not play it at all. You, or WDR, would have noticed this problem very early, you would have spoken to the packager and they would have fixed the problem in the packager. Then the file would have been re-encoded correctly.

By not being strict, players force other player to support strictly speaking invalid content as well. This makes the implementation of such players not only more complex, but likely also less efficient (battery) and slower (user experience). You might know the Internet Explorer-situation in which all web browsers are forced to support crappy content. All web developer love that ;)

This is why in my opinion, supporting such content is bad for the ecosystem and the industry as a whole. However, as this is my personal opinion, it is completely irrelevant. :)

---- end of personal opinion ----<

[ojw28]

I'm not convinced the media is broken. I think the problem might be that ISO 14496-12 and Apple's QuickTime specification define the MetaBox differently:

1. In Apple's QuickTime specification, the MetaBox is a regular Box.
2. In ISO 14496-12, MetaBox extends FullBox.

The difference is that a FullBox has 4 extra bytes for version and flag data after the type, which is exactly what we're seeing here. Our code currently assumes the QuickTime definition, and so fails when it encounters these extra bytes in the ISO 14496-12 definition.

If you look in Mp4Extractor and AtomParsers you'll see a few usages of a isQuickTime boolean, where we're working around other awkward differences between the two specifications. We probably need to do something similar for this case too.

[marcbaechinger]

@gemiren @asaadaa You may have seen the clarification about QuickTime/ISOMP4 above. So, please
accept my apologies for saying your content is invalid when obviously it is not. :)

We have provided a fix to handle both variants of the meta atom correctly. I tested with your files and both play fine.

The fix will be included in the upcoming 2.10 release.