Exoplayer: CMAF Content No Longer Working on v2.12

[austinchristensen]

Issue description

CMAF streams that worked on v2.11 of exoplayer no longer play on v2.12, giving the error: Caused by: com.google.android.exoplayer2.ParserException: Cannot find sync byte. Most likely not a Transport Stream.
Seems to be related to this issue: https://github.com/google/ExoPlayer/issues/8219
However, to us this seems to be a regression. We are having content that has been working without issue on 2.11.5, that is now broken.

Reproduction steps

Using the app below, run the app and play either of the two assets available on the launch screen.
https://github.com/austinchristensen/exoPlayerMP4ErrorDemo/tree/master

Link to test content

Here are the two assets that are embeded in the app:
https://static.realeyes.cloud/android/cmaf/master_cmaf.m3u8
https://static.realeyes.cloud/android/cmaf2/master_cmaf.m3u8

A full bug report captured from the device

E/ExoPlayerImplInternal: Playback error
com.google.android.exoplayer2.ExoPlaybackException: Source error
at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:554)
at android.os.Handler.dispatchMessage(Handler.java:103)
at android.os.Looper.loop(Looper.java:237)
at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: com.google.android.exoplayer2.ParserException: Cannot find sync byte. Most likely not a Transport Stream.
at com.google.android.exoplayer2.extractor.ts.TsExtractor.findEndOfFirstTsPacketInBuffer(TsExtractor.java:453)
at com.google.android.exoplayer2.extractor.ts.TsExtractor.read(TsExtractor.java:320)
at com.google.android.exoplayer2.source.hls.BundledHlsMediaChunkExtractor.read(BundledHlsMediaChunkExtractor.java:67)
at com.google.android.exoplayer2.source.hls.HlsMediaChunk.feedDataToExtractor(HlsMediaChunk.java:405)
at com.google.android.exoplayer2.source.hls.HlsMediaChunk.maybeLoadInitData(HlsMediaChunk.java:358)
at com.google.android.exoplayer2.source.hls.HlsMediaChunk.load(HlsMediaChunk.java:339)
at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:415)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)

Version of ExoPlayer being used

v2.12.2 on master branch (error) and v2.11.8 on workingOnV2.11.8 branch

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

Galaxy S9 on android v10

[christosts]

@kim-vde can you take a look?

[AquilesCanta]

This is actually most likely an HLS issue. I can take a look.

[AquilesCanta]

The reason for this is that the mp4 files report brand iso9 which is not yet listed as supported.

I haven't checked yet what changed since 2.11, since it seems unlikely that we removed supported brands at any point. In any case, this will most likely be fixed in the next release. And a commit will appear here once we've pushed a fix to the dev-branch.

[ojw28]

This seems identical to https://github.com/google/ExoPlayer/issues/8219. I'm not really sure I follow some of the comments on that issue. In particular:

My two cents. Falling back to TsExtractor has historic reasons (for example, #4033), and even though I agree falling back according to the extension is a reasonable improvement, there may be people relying on that mechanism now.

It looks like we _did_ fall back according to extension in 2.11 (here), and that we no longer do so. It's unclear to me why we stopped doing that. I think this is also why there is a difference between 2.11 and 2.12.

[jgainfort]

Thank you for taking a look!

The reason for this is that the mp4 files report brand iso9 which is not yet listed as supported.

I haven't checked yet what changed since 2.11, since it seems unlikely that we removed supported brands at any point. In any case, this will most likely be fixed in the next release. And a commit will appear here once we've pushed a fix to the dev-branch.

Regrading iso9, the files we provided were made generically through encoding.com which alot of our clients use. That cmaf file plays everywhere for us except this one particular version of Exo. It would be a hard sell to say that we need to change our encoding just for this one particular version. 2.12 brought a fix that we needed in regards to DRM and clear contet ads so adding support back for this condition would be truly appreciated. Is there anything we can help with?

This seems identical to #8219. I'm not really sure I follow some of the comments on that issue. In particular:

My two cents. Falling back to TsExtractor has historic reasons (for example, #4033), and even though I agree falling back according to the extension is a reasonable improvement, there may be people relying on that mechanism now.

It looks like we _did_ fall back according to extension in 2.11 (here), and that we no longer do so. It's unclear to me why we stopped doing that. I think this is also why there is a difference between 2.11 and 2.12.

I believe this may be an unintended side effect. We seem to not be the only ones running into this error.

In the meantime we are experimenting with a custom extractor factory as suggested in the original ticket. If we get that working we can post here for others as well.

[matamegger]

What was a quite strong argument in the other issue is IMO:

Regarding the content you provided: according to annex E of ISO/IEC 14496-12:2015, the brands in the input file serve as a permission to the reader to read the file. If a reader supports iso2-6 only, a file with brand iso9 only indicates that the reader shouldn't attempt to play the file. So I am not sure it is an improvement to fall back to the FragmentedMp4Extractor in this specific case.

This meant to me that there are are 2 ways of fixing this "properly":

• Implementing support for iso9 brand
• Do not fall back to an unrelated Extractor, but directly fail
• ([specific for my test streams] Correct the brand in the stream, as the iso9 features are actually not needed)

Admit, I should have more emphasized that this change with 2.12.0.

[ppatlolla-turner]

How soon there would be support for iso9 brand by the exoplayer? We are in the middle of updating exoplayer to the latest version(2.12.*).
We at WarnerMedia have a huge catalog of ISO BMFF files encoded using iso9 brand.

[AquilesCanta]

We have added the brand check internally, which will probably make it in the next release (I assume 2.12.3). I cannot provide any timelines for that though.

[austinchristensen]

CustomHlsExtractorFactory.java.zip

Here's what we came up if anyone wants to use it. We took the 2.12 DefaultHlsExtractorFactory and used pieces from the 2.11 version to get playback.