Live Smooth-Streaming playback issues

[moacir69]

The following live Smooth-Streaming stream no longer plays in ExoPlayer 2.0.4 demo application:

http://essdrmproducts-dev.insidesecure.com:9090/live/clear.isml/manifest

It was playing in ExoPlayer 1.5.8 demo application. In the logs, the following error shows up:

com.google.android.exoplayer2.ExoPlaybackException
at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:310)
at android.os.Handler.dispatchMessage(Handler.java:98)
at android.os.Looper.loop(Looper.java:136)
at android.os.HandlerThread.run(HandlerThread.java:61)
at com.google.android.exoplayer2.util.PriorityHandlerThread.run(PriorityHandlerThread.java:40)
Caused by: com.google.android.exoplayer2.ParserException: Offset to sample data was negative.
at com.google.android.exoplayer2.extractor.mp4.FragmentedMp4Extractor.readSample(FragmentedMp4Extractor.java:950)
at com.google.android.exoplayer2.extractor.mp4.FragmentedMp4Extractor.read(FragmentedMp4Extractor.java:228)
at com.google.android.exoplayer2.source.chunk.ChunkExtractorWrapper.read(ChunkExtractorWrapper.java:111)
at com.google.android.exoplayer2.source.chunk.ContainerMediaChunk.load(ContainerMediaChunk.java:115)

In order to reproduce the issue, you just need to add the related content to the demo app samples and attempt to start the playback, in any device.
Can you please investigate this issue?
Please, let me know if any further information is needed.
Kind regards,

Moacir

[ojw28]

Please search for existing issues. Specifically, #1152. It's likely this case is the same.

[moacir69]

Hi,
I have already tried the workaround suggested in #1152, but that does not fix the issue. Also, that behaviour was observable in ExoPlayer 1.5.3 while this issue is happening in 2.0.4, but not in 1.5.8.
Warm regards,

Moacir

[ojw28]

The sample "works" in 1.5.8, but if you look at logcat you'll still see that error being spammed repeatedly into the logs. The reason it still plays successfully is because there was another bug that would then cause the extractor to retry from the wrong position in the data. This bug has since been fixed.

The issue is exactly the same case as in #1152. It looks like the content provider has at some point inserted extra UUID atoms that are 61 bytes long between the trun and mdat atoms in the streams. To do this in a valid way, they should have also updated the data_offset in the trun atom to be 61 larger than it was before, but they haven't done this. Hence the stream is invalid, and you should report this to the content provider.

atom	size
---------------------
trun	1712	<-- Contains data_offset whose value is 61 smaller than it should be.
uuid	44
uuid	61	<-- Hypothesis is that this atom was inserted later.
mdat	1873

You can pretty easily work around this issue by commenting out L940-L953 (inclusive) of FragmentedMp4Extractor (line numbers accurate for r2.0.4).

[moacir69]

Thanks for the quick analysis!
I will follow your suggestion and verify if it works.
Kind regards,

Moacir

[moacir69]

Thank you, indeed it worked.
Kind regards,

Moacir