player.seekTo vs presentationTimeUs in overlay.getTextureId is wrong

[steelbytes]

Version

Media3 1.5.1

More version details

No response

Devices that reproduce the issue

pixel 8pro

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Not tested

Reproduction steps

player.playWhenReady = false
player.setVideoEffects(myEffects)
player.setMediaItem(mediaItem)
player.prepare()
player.seekTo(exoPos)
watch presentationTimeUs in myTextureOverlay.getTextureId()

Expected result

presentationTimeUs in textureOverlay.getTextureId should start counting from the start of the file.

Actual result

presentationTimeUs in textureOverlay.getTextureId should from the seek position.

Media

all files tested

Bug Report

• You will email the zip file produced by adb bugreport to [email protected] after filing this issue.

[steelbytes]

can't test in demo app as can't compile your git repo on windows with AS koala. I used to be able to with older pulls.

[claincly]

Expected result: presentationTimeUs in textureOverlay.getTextureId should start counting from the start of the file.

This is not the expected behaviour. The effect timestamp will start from exoPos instead, if you want the timestamp to start from zero, you need to manually subtract the offset in your effect.

[steelbytes]

well it reall

Expected result: presentationTimeUs in textureOverlay.getTextureId should start counting from the start of the file.

This is not the expected behaviour. The effect timestamp will start from exoPos instead, if you want the timestamp to start from zero, you need to manually subtract the offset in your effect.

:-(
it feels like a bug. I haven't checked but is that the way it's documented?

[claincly]

No it's not formally documented, but the implementation follows the principle of ExoPlayer, where after you seek, the position is reset to the seeked position.

[steelbytes]

well trying to workaround this produces inconsistent results. guess I'm just going to have to fork it.

[steelbytes]

AND presentationTimeUs is sometimes negative.

[claincly]

The presentationTimeUs should not be negative - could you share how did you trigger this to happen?

[steelbytes]

The presentationTimeUs should not be negative - could you share how did you trigger this to happen?

It happens when I to the above use of seekTo AND then bash the skip backwards/forwards and seek bar a bit.

[steelbytes]

ok, here's a trivial repro for negative time

1. pull https://github.com/steelbytes/media3test
2. add overlay code below to the existing list (can remove Crop)
3. add player.seekTo(60*1000L) after prepare
4. adb logcat -e negative -T 0
5. compile & run
6. click the go to start arrow in the ui (standard controller)
7. wait for it to load and render the frame
8. observe logcat and yo'ull see the negative

                OverlayEffect(ImmutableList.Builder<TextureOverlay>().add(object : TextOverlay() {
                    override fun getText(presentationTimeUs: Long): SpannableString = SpannableString("test")
                    override fun getTextureId(presentationTimeUs: Long): Int {
                        if (presentationTimeUs < 0L)
                            Log.d("Media3Test", "negative presentationTimeUs " + presentationTimeUs)
                        return super.getTextureId(presentationTimeUs)
                    }
                }).build())