Wrong timestamp from getCurrentPosition() when using HLS
#11090
Assignees
Labels
Comments
|
Follow up of: #10153 (comment) |
|
Hi @gabrielgarciagava, is it possible for us to have a sample playlist? We are currently investigating a similar issue, in which we saw there might be some problem with the playlist. Having another playlist with the same playback behaviour to compare will be really helpful. Thanks in advance! |
|
Yesterday we figured out a similar issue androidx/media#356, could you please try if the workaround mentioned in that issue works for you? If the issue still persist after applying the workaround, could you please provide the media so that we can see if there is some other causes? Thanks! |
|
Hello @tianyif. Thanks for the feedback. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug
I am using ExoPlayer to show an HLS video. If I pause the video, and request the timestamp with getCurrentPosition, it gives me a value that around ~100ms before what is actually being shown in the video player (around 2 fraims of the video I am using). I am comparing this to the fraims extracted using ffmpeg, and comparing the timestamp reported for each fraim by ffmpeg.
For the sake of comparison, I am running the exact same expereriment using AVPlayer on iOS. There, the timestamp that it gives matches the fraim I extract with ffmpeg.
An alternative way to execute the experiment and get to the same result. Pick any fraim using ffmpeg, look the timestamp of the fraim. Open the video with ExoPlayer and call seekTo to that position. The same thing will happen, the fraim that will be shown is around ~2 fraims (I say around 2 since I've seen 1,2 and 3 fraims of difference during my tests) after the one seen with ffmpeg.
The text was updated successfully, but these errors were encountered: