Smooth Streaming with AVC1 video is braking FragmentedMp4Extractor with exception

[alekmarinov]

We have live Smooth Streaming streams with Subtype="AVC1" attribute in the StreamIndex tag and FourCC="AVC1" in each QualityLevel subtag.

The demo ExoPlayer branch release-v2 executed on NexusPlayer with Android v7 is causing the exception as in the attached logcat, which is leading to FragmentedMp4Extractor parser.

The demo Smooth Streaming streams of ExoPlayer are encoded with FourCC="H264" and they work normally.

We found a reference in MSDN doc explaining about a small (but essential) difference between AVC1 and H264 which should brake the parsing if not taken in mind:
'AVC1' H.264 bitstream without start codes.
'H264' H.264 bitstream with start codes.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd757808(v=vs.85).aspx?tduid=(18b898c858bc2b85cd9349dac3482811)(256380)(2459594)(TnL5HPStwNw-aixJO4zLgn.rofQVnLj9Vw)()

Does someone have any recommendations regading this problem?

ExoPlayer2_SmoothStreaming_AVC1.txt

[ojw28]

I could be wrong, but I don't think the doc you reference is relevant to SmoothStreaming. We've always unconditionally assumed that SmoothStreaming uses length-delimited NAL units (i.e. without start codes, or AVC1 style in the doc you reference). Hence FourCC="H264" does not seem to imply start-code-delimited NAL units in SmoothStreaming, else the samples we have wouldn't work.

The parser is definitely failing to parse your content, but without a sample stream or at least a working snapshot of it, we'll not be able to debug the issue. Please provide sample media if you wish for us to take a further look.

[alekmarinov]

Thanks for your answer. Can you please check the email dev.exoplayer@gmail.com for the reference streams sent on 12. Oct?

Just after I published this issue found this one #1152 which is closed but explains precisely the same problem -> "bytesToSkip is always -61"

Your reply there is to comment out the part which causes the exception and that appears to work for my case as well.
I commented out the code bellow in FragmentedMp4Extractor.java and the stream started to work but since one time crashed wish to test a bit more before giving a final feedback.

The guy from issue #1152 ends the discussion with "I will let the content provider know about the issue.", but I believe the FMP4 parser may need a small enhacement for these 2 cases and maybe more out there. I will leave it to you to decide the appropriate actions.

926: // We skip bytes preceding the next sample to read.
// int bytesToSkip = (int) (nextDataPosition - input.getPosition());
// if (bytesToSkip < 0) {
// if (nextDataPosition == currentTrackBundle.fragment.atomPosition) {
// // Assume the sample data must be contiguous in the mdat with no preceeding data.
// Log.w(TAG, "Offset to sample data was missing.");
// bytesToSkip = 0;
// } else {
// throw new ParserException("Offset to sample data was negative.");
// }
// }
// input.skipFully(bytesToSkip);

[alekmarinov]

Just to add one more fact that the same as in #1152 the issue is happening only with Live streams.

[ojw28]

I don't really understand your comment about the FMP4 parser needing an enhancement. The source media is broken, and the fix is to correct the media to be valid.

[alekmarinov]

Based on your feedback our streaming provider will take actions to investigate the issue from the encoder side. I will comment here the results when they find something.
Thank you!