Repository navigation
Seeking into AC4 audio only content with FMP4 subfragments creates discontinuities #11000
Description
ExoPlayer Version
2.15.1
Devices that reproduce the issue
- Samsung S11 with Android 11
Devices that do not reproduce the issue
Google Pixels as they do not support decoding the Dolby AC-4 codec
Reproducible in the demo app?
Yes
Reproduction steps
- Play attached media
- Seek the player forward
- Watch playhead snap to the beginning of the segment instead of seeking to specified point
Expected result
Player seeks to IFrame as close to specified point as possible, parsing subfragments within the segment accordingly.
Actual result
Player detects discontinuity and snaps to the closest Iframe at beginning of segment
Media
Will email clear AC4 media separately
Bug Report
- You will email the zip file produced by
adb bugreportto dev.exoplayer@gmail.com after filing this issue.
Activity
ronak2121 commentedon Feb 18, 2023
Just to note that if we set the fragment sizes to be the same as the segments this doesn’t happen.
it’s only when fragments are smaller that Exoplayer doesn’t take subfragments into account when finding the appropriate IFrame.
[-]Seeking into AC4 content with FMP4 subfragments creates discontinuities[/-][+]Seeking into AC4 audio only content with FMP4 subfragments creates discontinuities[/+]ronak2121 commentedon Feb 20, 2023
Also to note, this works just fine for audio codecs that don’t use IFrames such as AAC, DD+JOC.
ronak2121 commentedon Feb 21, 2023
Here's what we've traced so far:
ronak2121 commentedon Feb 21, 2023
FYI that we've emailed our media and ADB log dump as requested
ronak2121 commentedon Feb 21, 2023
We’re working on a PR that should resolve this issue. My coworker (@hcgil) will post it within the next day or so.
hcgil commentedon Feb 22, 2023
Just put up a PR with a rough solution to the problem we're encountering. More info is given above as well as in the pr description - from the looks of it we're starting playback at the end of the first fragment because we cannot guarantee the presence of sync frames later on. This PR should resolve this by keeping a record of which samples we've encountered since the last sync frame, and committing them (and any successive frames) once we reach our start time, to hopefully decrease the magnitude of discrepancies when seeking.
ronak2121 commentedon Mar 1, 2023
Hi @rohitjoins we learned that xHE-AAC May also impacted by this issue. Have you had a chance to look at our PR? We're working with Dolby on this to ensure they are aligned with our suggested solution, but we're looking for your guidance as well.
rohitjoins commentedon Mar 1, 2023
@ronak2121 I haven't had the time to look into this yet. You can expect a reply from me by next week. Thanks :)
ronak2121 commentedon Mar 11, 2023
@rohitjoins FYI that we’ve received confirmation from Dolby that this fix is the correct one. Please advise.
ronak2121 commentedon Mar 14, 2023
Hi @rohitjoins any update? This issue is blocking a critical upcoming launch for us. Can you please look into this?
rohitjoins commentedon Mar 14, 2023
@ronak2121 Sorry for the late reply. I only see the bug report attached to the email you have sent to us and not the media. Can you please send the media? And also confirm here when it is done. Thanks.
36 remaining items
rohitjoins commentedon May 24, 2023
Just quickly wanted to let you know that these were bug fix releases. We are trying our best to accommodate this fix in our next normal release. Will keep you posted.
tonihei commentedon Jun 7, 2023
We have a fix for this issue, but it's quite risky to submit it as it touches code that is used in many different scenarios and we like to let it sit for a bit with internal apps to ensure it doesn't break anything.
For more context: The underlying reason for what you are seeing is that the AC4 decoder on this device produces decoded output samples with timestamps that are different from the input sample timestamps. This is technically allowed, but we have some remaining code in ExoPlayer that relies on matching timestamps (because historically, this used to be always true). Our plan is to remove this dependency on matching timestamps, but as I said in the first paragraph, it touches an area where we've seen many variations of different behaviors and we need to be careful not to break another use case by fixing this one. We will likely push a change to GitHub fairly soon, so you are free to pick this up by depending on the source or wait until the next release (1.2.0).
ronak2121 commentedon Jun 7, 2023
awesome thanks for the update!
ronak2121 commentedon Jun 14, 2023
Is this the commit you're referencing @tonihei ? 08c189e#diff-793f10aa618621cccb28e4b688e95913b4027a13a39616c136c20b4695b41f9a
Mark output sample as decode-only based on start time
Mark output sample as decode-only based on start time
tonihei commentedon Jun 15, 2023
No, the fix commit is the one linked in the issue above (cf02581). I can also close the issue for now since the issue has been fixed, but as noted already it won't be released until Media3 1.2.0.
Rollback of b69b332
Rollback of cf02581
Rollback of 40a5e9c
Rollback of 7996766