Support key-frame accurate seeking in HLS

[mohammed-atif]

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

@Override
    public boolean onScroll(MotionEvent e1, MotionEvent e2, float distanceX, float distanceY) {
        long seekTo = (long) (mPlayer.getCurrentPosition() - distanceX);
        Log.d(TAG, "current scroll position "+seekTo);
        mPlayer.seekTo(seekTo);
        return true;
    }

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?

[ojw28]

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.

[mohammed-atif]

@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?

[goffioul]

@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.

[mohammed-atif]

@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.

int currentTime =  mSimpleExoPlayer.getCurrentTime();
int seekToMillis = currentTime - 45; //seek duration is very small in the range of 30 to 60 milliseconds
mSimpleExoPlayer.seekTo(seekToMillis);

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?

[ojw28]

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.

[green-nick]

Hi, @ojw28
When we could see key-frame supporting on release? Will it be in 2.6.2?
Or does dev-branch stable enough?

[ojw28]

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.

[green-nick]

@ojw28 Ok, thanks!

[jclova]

Really hoping to see the seekTo() options for us to choose:

1. Accurate/slow seek
2. To nearest keyframe/fast seek.

[ojw28]

This is supported for all media types except HLS in 2.7.0, which will be released shortly, via ExoPlayer.setSeekParameters.

[ojw28]

2.7.0 is now released, so this is now supported except for when playing HLS content.

[jclova]

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> .

[animaonline]

When will this be support for HLS streams?

[ojw28]

We do not have an ETA for supporting this for HLS.

[BrainCrumbz]

Hi all. Does anyone know how key-frame accurate seeking is reflected in SeekParameters "constants" (ref.)?

Which one should be passed to setSeekParameters() in order to achieve:

1. any frame accurate seeking
2. key-frame accurate seeking

?

TA

[andrewlewis]

@BrainCrumbz If you want to snap the seek position to the closest keyframe use SeekParameters.CLOSEST_SYNC. To see to a exact frame (the frame before the requested position, even if it's not a keyframe) use SeekParameters.EXACT.

[BrainCrumbz]

@ 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.

[ojw28]

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.

[tipoc123]

Do you have some enhancements for HLS seek? Current HLS seek is slow and not suitable for production use (ExoPlayer 2.9.6)

[NathanSass]

I agree. It would be great to see this scheduled ASAP

[Zoeie]

Like the MediaPlayer, it's just return the start position of the ts which the seek point owns to. The seeking operation is fast。
How should I modify the Exo source to be the same as the Seeking of MediaPlayer?

[stevemayhew]

@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 DefaultDashChunkSource's method, getAdjustedSeekPositionUs() obviously the playlist would need to support and be marked with #EXT-X-INDEPENDENT-SEGMENTS for this to work. Also before / after tolerances less than a segment duration would not really work (as there is no way to know the GOP interval in the HLS segments data). For I-Frame only, this does not matter trivially as each segment contains only a single i-Frame.

Scrub seeking (like the original request is for) is best done in i-Frame mode, so we could restrict the getAdjustedSeekPositionUs() function to only adjust the position when the primary sample stream wrapper is I-frame only.

[jonas-livesporttv]

@ojw28 you closing this issue means that key-frame accurate seeking in HLS is possible now?

[ojw28]

I believe support was added by @stevemayhew in the merged pull requests referenced above.