You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Live DAI DASH streaming freezing with multi periods and no closed caption Ad. #1863
there seems should be a check for ceaInputBuffer.timeUs != C.TIME_END_OF_SOURCE when discarding the ceaInputBuffer.
Without this check, the playback could be stuck due to the text render is keeping waiting for end of source.
I think I was able to repro the issue using the media links provided over email. I then added a single log line and went to retry, and now the content is consistently 503ing.
Could you please check to make sure the content is still accessible?
I've tried with the following code in CeaDecoder and playback no longer seems to hang:
if (ceaInputBuffer.timeUs != C.TIME_END_OF_SOURCE
&& outputStartTimeUs != C.TIME_UNSET
&& ceaInputBuffer.timeUs < outputStartTimeUs) {
// We can start decoding anywhere in CEA formats, so discarding on the input side is fine.releaseInputBuffer(ceaInputBuffer);
} else {
Thanks for reporting! I'll work on getting this fix reviewed internally and merged.
I've also noticed that the subtitles in your content are mixed up/garbled on main (and likely will be in 1.5.0-rc01 too though I haven't checked) - I'm looking into this as well, as it's likely related to some changes after 1.4.1 (we've seen and fixed similar symptoms recently, but this must be a case we haven't fixed yet).
The fix for the CeaDecoder is submitted and linked above.
I also investigated the garbled captions. The problem is due to your MP4 container marking every video sample as a keyframe, meaning that we flush our reordering queue of CEA-608 samples here on every sample (which means it can't re-order anything):
This MP4 metadata is inconsistent with the H.264 bytes contained in each sample (not every H.264 sample is a keyframe).
If I change the if condition to just (trackBundle.getCurrentSampleFlags() & C.BUFFER_FLAG_END_OF_STREAM) != 0 then the subtitles become un-garbled (because the queue is able to correctly re-order the out-of-order samples). However, I'm not sure this is a correct change in general (we should be able to rely on flushing our queue on each keyframe, and we should be able to rely on the MP4 keyframe metadata being correct).
This seems to be an issue with your content muxing, rather than with ExoPlayer's logic - I suggest you report it to whoever is producing your content.
We discussed as a team and decided the benefit of relying on the MP4 sync sample metadata for flushing is marginal, and the result of poor behaviour on malformed media like this is quite catastrophic - so we decided to remove the assumption that MP4 sync sample metadata is correct for this use-case (re-ordering SEI CEA-608 samples) - see the change linked above.
Activity
linhai326 commentedon Nov 7, 2024
We believe this bug was introduced in 1.4.0 when removing "IsDecodeOnly" commits:
0f42dd4
6e0f8e3
Particularly, it seems this is the bug, in CeaDecoder.java, line 88, in queueInputBuffer():

https://github.com/androidx/media/blob/release/libraries/extractor/src/main/java/androidx/media3/extractor/text/cea/CeaDecoder.java
there seems should be a check for ceaInputBuffer.timeUs != C.TIME_END_OF_SOURCE when discarding the ceaInputBuffer.
Without this check, the playback could be stuck due to the text render is keeping waiting for end of source.
linhai326 commentedon Nov 12, 2024
any update?
icbaker commentedon Nov 12, 2024
I think I was able to repro the issue using the media links provided over email. I then added a single log line and went to retry, and now the content is consistently 503ing.
Could you please check to make sure the content is still accessible?
icbaker commentedon Nov 12, 2024
The content seems to be working again now.
I've tried with the following code in
CeaDecoderand playback no longer seems to hang:Thanks for reporting! I'll work on getting this fix reviewed internally and merged.
I've also noticed that the subtitles in your content are mixed up/garbled on
main(and likely will be in1.5.0-rc01too though I haven't checked) - I'm looking into this as well, as it's likely related to some changes after 1.4.1 (we've seen and fixed similar symptoms recently, but this must be a case we haven't fixed yet).Handle `C.TIME_END_OF_SOURCE` buffer timestamps in `CeaDecoder`
icbaker commentedon Nov 12, 2024
The fix for the
CeaDecoderis submitted and linked above.I also investigated the garbled captions. The problem is due to your MP4 container marking every video sample as a keyframe, meaning that we flush our reordering queue of CEA-608 samples here on every sample (which means it can't re-order anything):
media/libraries/extractor/src/main/java/androidx/media3/extractor/mp4/FragmentedMp4Extractor.java
Lines 1650 to 1652 in 19b38c8
This MP4 metadata is inconsistent with the H.264 bytes contained in each sample (not every H.264 sample is a keyframe).
If I change the
ifcondition to just(trackBundle.getCurrentSampleFlags() & C.BUFFER_FLAG_END_OF_STREAM) != 0then the subtitles become un-garbled (because the queue is able to correctly re-order the out-of-order samples). However, I'm not sure this is a correct change in general (we should be able to rely on flushing our queue on each keyframe, and we should be able to rely on the MP4 keyframe metadata being correct).This seems to be an issue with your content muxing, rather than with ExoPlayer's logic - I suggest you report it to whoever is producing your content.
linhai326 commentedon Nov 12, 2024
@icbaker
Thanks a lot for looking into this issue.
We will check with our content provider!!
Don't assume MP4 keyframe metadata is correct for CEA re-ordering
icbaker commentedon Nov 15, 2024
We discussed as a team and decided the benefit of relying on the MP4 sync sample metadata for flushing is marginal, and the result of poor behaviour on malformed media like this is quite catastrophic - so we decided to remove the assumption that MP4 sync sample metadata is correct for this use-case (re-ordering SEI CEA-608 samples) - see the change linked above.
Handle `C.TIME_END_OF_SOURCE` buffer timestamps in `CeaDecoder`
Don't assume MP4 keyframe metadata is correct for CEA re-ordering
Don't assume MP4 keyframe metadata is correct for CEA re-ordering
Handle `C.TIME_END_OF_SOURCE` buffer timestamps in `CeaDecoder`
Don't assume MP4 keyframe metadata is correct for CEA re-ordering