Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flickering subtitles in DASH/H264 with B-frames present #288

Closed
1 task
AGasztold opened this issue Mar 31, 2023 · 7 comments
Closed
1 task

Flickering subtitles in DASH/H264 with B-frames present #288

AGasztold opened this issue Mar 31, 2023 · 7 comments
Assignees
Labels

Comments

@AGasztold
Copy link

AGasztold commented Mar 31, 2023

Media3 Version

ExoPlayer 2.18.3

Devices that reproduce the issue

All Android devices.

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Yes

Reproduction steps

  1. Run attached media in Demo app
  2. Turn on subtitles
  3. Observe the flicker effect

Expected result

No flickering effect should be observed.

Actual result

Due to the presence of B frames in text chunks and the time offset of text segment relative to video segments:

SegmentTimeline for text: <S t="19" d="2000" r="283" />
SegmentTimeline for video: <S t="0" d="2000" r="89" />

there is an effect of flickering subtitles. When I applied the following workaround inside SubtitleOutputBuffer:

  public void setContent(long timeUs, Subtitle subtitle, long subsampleOffsetUs) {
    this.timeUs = (timeUs/1000000L) * 1000000L;
    this.subtitle = subtitle;
    this.subsampleOffsetUs =
        subsampleOffsetUs == Format.OFFSET_SAMPLE_RELATIVE ? this.timeUs : subsampleOffsetUs;
  }

which cancels this offset, flickering effect does not occur. Anyaway, this is not long term solution for me. I will appreciate your help.

Media

https://r.dcs.redlabs.pl/dash/o2/ATM-Lab/zos/vod-test/glitch/dash_b_frames/playlist.smil

Bug Report

@icbaker
Copy link
Collaborator

icbaker commented Apr 5, 2023

Thanks for reporting, and for including a repro stream. I'm able to see the same issue.

I've added some debug logging and it looks like this happens when we transition between Subtitle objects inside TextRenderer while a cue is meant to be shown on screen. The implementation details of this means we currently end up 'finishing' one Subtitle object with an empty list of cues at the same presentation timestamp of the first event of the next Subtitle (which contains the same cue text that should be on screen). This transition through an empty cue list is then propagated through TextOutput and ultimately to the SubtitleView and results in the flickering. We end up seeing
cues emitted roughly as follows (the timestamps are from your example media, the text I swapped out for this example):

positionUs=1000037010972  presentationTimeUs=37000000  cues=["foo bar"]  subtitle_1
positionUs=1000038002287  presentationTimeUs=38000000  cues=[]  subtitle_1
positionUs=1000038022400  presentationTimeUs=38000000	cues=["foo bar"]  subtitle_2

I'm still investigating exactly how the media results in this output.

@AGasztold
Copy link
Author

Hello, thanks for your reply. Are the any news regarding this issue? I will appreciate your help.

@07steven01
Copy link

I'm facing the same issue. Is there a fix yet?

@icbaker
Copy link
Collaborator

icbaker commented Jul 19, 2023

I'm currently making some fairly major changes to TextRenderer that should resolve the problem I described above - I hope this will be part of 1.2.0.

@07steven01
Copy link

I can see 1.2.0-alpha01 is out. No mention of TextRenderer in the changelog. Are the changes still planned for 1.2.0 or rather some further release?

@icbaker
Copy link
Collaborator

icbaker commented Sep 13, 2023

I'm working on the TextRenderer changes (they are not submitted yet) - at the moment i'm not sure if they will be complete in time for 1.2.0.

copybara-service bot pushed a commit that referenced this issue Oct 5, 2023
The existing `Subtitle` handling code is left intact to support the
legacy post-`SampleQueue` decoding path for now.

This also includes full support for merging overlapping `CuesWithTiming`
instances, which explains the test dump file changes, and which should
resolve the following issues (if used with the
decoder-before-`SampleQueue` subtitle logic added in
5d453fc):

* Issue: google/ExoPlayer#10295
* Issue: google/ExoPlayer#4794

It should also help resolve Issue: #288, but that will also require
some changes in the DASH module to enable pre-`SampleQueue` subtitle
parsing (which should happen soon).

#minor-release

PiperOrigin-RevId: 571021417
copybara-service bot pushed a commit to google/ExoPlayer that referenced this issue Oct 5, 2023
The existing `Subtitle` handling code is left intact to support the
legacy post-`SampleQueue` decoding path for now.

This also includes full support for merging overlapping `CuesWithTiming`
instances, which explains the test dump file changes, and which should
resolve the following issues (if used with the
decoder-before-`SampleQueue` subtitle logic added in
304dadc):

* Issue: #10295
* Issue: #4794

It should also help resolve Issue: androidx/media#288, but that will also require
some changes in the DASH module to enable pre-`SampleQueue` subtitle
parsing (which should happen soon).

#minor-release

PiperOrigin-RevId: 571021417
copybara-service bot pushed a commit that referenced this issue Oct 10, 2023
This currently only applies to subtitles muxed into mp4 segments, and
not standalone text files linked directly from the manifest.

Issue: #288

#minor-release

PiperOrigin-RevId: 572263764
copybara-service bot pushed a commit to google/ExoPlayer that referenced this issue Oct 10, 2023
This currently only applies to subtitles muxed into mp4 segments, and
not standalone text files linked directly from the manifest.

Issue: androidx/media#288

#minor-release

PiperOrigin-RevId: 572263764
@icbaker
Copy link
Collaborator

icbaker commented Oct 17, 2023

I've added experimental support for the new approach to subtitle parsing in DASH. This will be included in 1.2.0-rc01. You can try it out with DashMediaSource.Factory.experimentalParseSubtitlesDuringExtraction.

rohitjoins pushed a commit that referenced this issue Oct 23, 2023
The existing `Subtitle` handling code is left intact to support the
legacy post-`SampleQueue` decoding path for now.

This also includes full support for merging overlapping `CuesWithTiming`
instances, which explains the test dump file changes, and which should
resolve the following issues (if used with the
decoder-before-`SampleQueue` subtitle logic added in
5d453fc):

* Issue: google/ExoPlayer#10295
* Issue: google/ExoPlayer#4794

It should also help resolve Issue: #288, but that will also require
some changes in the DASH module to enable pre-`SampleQueue` subtitle
parsing (which should happen soon).

PiperOrigin-RevId: 571021417
(cherry picked from commit 002ee05)
rohitjoins pushed a commit that referenced this issue Oct 23, 2023
This currently only applies to subtitles muxed into mp4 segments, and
not standalone text files linked directly from the manifest.

Issue: #288

#minor-release

PiperOrigin-RevId: 572263764
(cherry picked from commit 66fa591)
@icbaker icbaker closed this as completed Oct 27, 2023
@androidx androidx locked and limited conversation to collaborators Dec 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants