-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Support key-frame accurate seeking in HLS #2882
Comments
The reason behavior is different is that ExoPlayer does frame-accurate seeking (in all cases). I think VideoView does key-frame accurate seeking, which is faster but less accurate. We can use this issue to track supporting key-frame accurate seeking as an option, but it's low priority. |
@ojw28 , In other players, we have a callback which notifies about the successful seeking. If I make multiple calls for seek using onScroll method, I can ignore the inputs if seek is in progress, but in case of ExoPlayer there is no such callback and due to multiple seek requests, the performance of seeking further goes down. It would be really good if ExoPlayer too provides the callbacks for seek completion. Apart from that, as you mentioned about the key-frame seeking, can you provide me details about the class which I can look into to do minor tweaks at my end for better seeking? |
@atifmohammed Not sure this will help you, but I also needed some callback after seek completion. What I come up with was to drop a flag in my app when starting the seek operation, then listen to state change in onPlayerStateChanged. If my flag was set and the player state was STATE_READY, then I fired my callback. That seemed to work for my use case. |
@goffioul Thanks for the response, I figured it out few days ago but couldn't update here. While seeking the state goes to Buffer and after seek it shifts to ready. @ojw28 forward seek works good after adding the callbacks. But when I seek backwards, player's current time is not updated.
if seekToMillis is currentTime + duration then everything works good, but when seeking back, in STATE_READY, currentTime remains same after every seek action which causes back and forth jerk to the video. Is it avoidable by making any changes? |
You shouldn't rely on the player reporting exactly your seek position back through getCurrentTime. The reported position may be adjusted slightly. If you want to seek in tiny increments like this, you should find a way to keep track of the last position that you performed a seek in your own code, and subtract 45 from that value each time. With that approach each position you pass to seekTo really will be 45 less than the previous value passed. If we could keep this issue on topic, which is to support seeking to the nearest key-frame, that would be good. Thanks. |
Issue: #2882 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=177814974
Issue: #2882 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=178370038
Issue: #2882 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=178606133
Also fix ClippingMediaSource to consider the start position an artificial key-frame, and to properly offset the value returned by getAdjustedSeekPositionUs. Issue: #2882 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=179032243
Whilst the previous behavior was WAI and had the advantage of updating the position to be more exact when known, there were a couple of disadvantages: 1. If seeking to the very end of a period in a playlist when paused, the position adjustment could trigger a position discontinuity to the next period. 2. We de-duplicate seeks to the current playback position. The position adjustment can prevent this from being effective. This is particularly important with the new SeekParameters support. When seeking to nearest sync point it's often possible to de-duplicate seeks, but we cannot do so if the playback position adjusts away from the sync point's time. Issue: #2439 Issue: #2882 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=180540736
Issue: #2882 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=181314086
Hi, @ojw28 |
This avoids issues that can arise due to slight discrepancies between chunk start times (obtained from the manifest of segment index) and the timestamps of the samples contained within those chunks. Issue: #2882 ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=182054959
It will be 2.7.0 (I'm not sure whether we're doing any further 2.6.x releases, but if we are they wont include the relevant changes). We don't have an ETA yet. |
@ojw28 Ok, thanks! |
Really hoping to see the seekTo() options for us to choose:
|
This is supported for all media types except HLS in 2.7.0, which will be released shortly, via |
2.7.0 is now released, so this is now supported except for when playing HLS content. |
Hooray!!
Thank you so much for making the ExoPlayer awesome!
…On Feb 26, 2018 1:40 PM, "ojw28" ***@***.***> wrote:
2.7.0 is now released.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2882 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMi04vWEUd3vscTuV6vfsh7gkisu-419ks5tYvqhgaJpZM4Npcbs>
.
|
When will this be support for HLS streams? |
We do not have an ETA for supporting this for HLS. |
Hi all. Does anyone know how key-frame accurate seeking is reflected in Which one should be passed to
? TA |
@BrainCrumbz If you want to snap the seek position to the closest keyframe use |
@ maintainers: would you consider a tiny PR over javadoc for those constants, to better clarify what each means? Not sure if e.g. "seeking to the closest sync point" fully clarifies that's a keyframe. |
The documentation is deliberately vague, because exactly what happens depends a bit on the type of media being played. For DASH and SmoothStreaming, chunk boundaries are the sync points. If a chunk contains an additional keyframe somewhere in the middle, that's not considered as a sync point. For regular MP4, sync points are keyframes. For fragmented MP4, sync points are fragment boundaries. The takeaway here is that sync points are whatever the underlying format naturally supports. A sync point will nearly always be aligned with a keyframe, but it's not necessarily true that all keyframes will be considered sync points. |
Do you have some enhancements for HLS seek? Current HLS seek is slow and not suitable for production use (ExoPlayer 2.9.6) |
I agree. It would be great to see this scheduled ASAP |
Like the MediaPlayer, it's just return the start position of the ts which the seek point owns to. The seeking operation is fast。 |
@ojw28 and @AquilesCanta I'm looking at this now for I-Frame only playback. The issue there is when you scrub multiple i-Frames are loaded an discard before any first frame shows, so the delay runs into 100's of milliseconds depending on the network and size of i-Frames. My plan is to implement something similar to Scrub seeking (like the original request is for) is best done in i-Frame mode, so we could restrict the |
The HLS implementation of `getAdjustedSeekPositionUs()` now completely supports `SeekParameters.CLOSEST_SYNC` and it's brotheran, assuming the HLS stream indicates segments all start with an IDR (that is EXT-X-INDEPENDENT-SEGMENTS is specified). This fixes issue google#2882 and improves (but does not completely solve google#8592
The HLS implementation of `getAdjustedSeekPositionUs()` now completely supports `SeekParameters.CLOSEST_SYNC` and it's brotheran, assuming the HLS stream indicates segments all start with an IDR (that is EXT-X-INDEPENDENT-SEGMENTS is specified). This fixes issue google#2882 and improves (but does not completely solve google#8592
@ojw28 you closing this issue means that key-frame accurate seeking in HLS is possible now? |
I believe support was added by @stevemayhew in the merged pull requests referenced above. |
SimpleExoPlayer.seekTo(int millis) issue
I have seen several issues requesting the same feature of smoother seeking in Exoplayer
At one thread I have seen your reply mentioning about the decoder but Android's VideoView default seeking is much more smoother when compared to ExoPlayer or MediaPlayer
Here is my code for reference
I am using locally stored mp4 file to play using Exoplayer with TextureView
current exoplayer version - r2.4.1
com.google.android.exoplayer:exoplayer-core:r2.4.1
Are there any configurations that I have to change for smoother seeking?
The text was updated successfully, but these errors were encountered: