FYI @rohitjoins and @tonihei

FYI we've emailed the adb bug report to the above email address. We will send you sample audio later today. Would appreciate a set of eyes from your team on this soon.

We still think our original proposed patch from: google/ExoPlayer#11000 is the actual solution to the original problem rather than messing with timestamps....but open to hearing your guidance as well.

We've emailed an XHE-AAC stream as promised. An AC4 one will be forthcoming.

@rohitjoins, can you please advise on the next steps for this issue?

Hi @rohitjoins , is there any update?

@ronak2121 The xHE-AAC link you shared via email results in HTTP 403 errors for me. Could you check that it's accessible or provide more details on how to access it? Not sure what the link is targeting, but the most important thing to have for testing is the actual DASH manifest referencing real media files that show the problem.

Just emailed you guys again with a new link.

The link still gives 403 errors I'm afraid. Not sure if it expired or if there is another problem, but we can't really debug and look into the issue if it's not accessible to us.

Hi I emailed you a new link a few weeks ago. Please try it out.

Thanks for the new stream, I was now able to access it. We don't monitor this email address directly, so please let us know here is you send new information to make us aware.

I was able to reproduce the issue and it is caused by the fact that the second period starts in the middle of a segment. This requires the player to preroll the data from the beginning of the segment. For formats without specific keyframes, there is an optimization that skips the samples early (for AAC-LC), so it seems to work correctly. For other formats like xHE-AAC and AC-4, we need to start decoding at earlier samples and can't skip them directly. Usually they would be skipped later, after decoding, but our DASH implementation didn't expect that a period starts in the middle of a segment and thus simply played out the entire segment again.

We can look into solving this, by note that even if we report it correctly in our pipelines, the player likely enters a very short buffering state at the transition where it needs to flush and restart the codec.

The first segment has a duration of about 20 seconds and is supposed to start at around 10 seconds. The presentation time offset is applied correctly in some parts of the pipeline, but we don't tell the decoder that it needs to discard some of the data again. This is because of the wrong assumption that every DASH period starts at the beginning of a segment.

We have I-Frames on every ~1s fragment so I’m not following what you’re referring to there.

Each fragment has its own sample index table, so the player still needs to parse through the entire file to find the right point.

Thanks Tony. I get it now. Please let us know when this is closer to being fixed so we can test it out with our streams.

We submitted a fix for the main problem now (see commit above). But as highlighted earlier, there will still be a tiny buffering state at the transition point where ExoPlayer needs time to go through the decode-only samples it won't need for playback. Closing this issue as the remaining buffering is a wider performance improvement related to how we handle pre-roll samples at transition points.