向前拖动，进度条会往回跳

[wanzhang]

设置mMediaController.setInstantSeeking(true); 拖动进度条时，发现进度条会往回跳。调试发现，seek开始到seek complete返回的时间有2秒多，setProgress拿到了pos和最新设置的pos不一致。比较系统或第三方播放器seek时都是非常流畅的。 请教一下，这个问题有办法改进吗？ 我想实现边拖动，边预览的效果。

[wanzhang]

如果seek很快完成，可能会消除这个问题。 那seek为什么会消耗这么长时间呢？ 我播放的是本地视频。

[wanzhang]

Line 8521: 07-07 12:05:26.905 D/onProgressChanged( 8155): media seek new pos: 7946
Line 8579: 07-07 12:05:26.955 D/onProgressChanged( 8155): seekTo pos: 7946
Line 8581: 07-07 12:05:26.955 W/IJKMEDIA( 8155): IjkMediaPlayer_seekTo
Line 8583: 07-07 12:05:26.955 W/IJKMEDIA( 8155): ijkmp_seek_to(7946)
Line 8585: 07-07 12:05:26.955 W/IJKMEDIA( 8155): ijkmp_seek_to(7946)=0
Line 8587: 07-07 12:05:26.955 W/IJKMEDIA( 8155): ijkmp_get_msg: FFP_REQ_SEEK
Line 8589: 07-07 12:05:26.955 E/IJKMEDIA( 8155): stream_seek 7946000(7946) + 0, 
Line 8591: 07-07 12:05:26.955 D/IJKMEDIA( 8155): ijkmp_get_msg: FFP_REQ_SEEK: seek to 7946
Line 8591: 07-07 12:05:26.955 D/IJKMEDIA( 8155): ijkmp_get_msg: FFP_REQ_SEEK: seek to 7946
Line 8597: 07-07 12:05:26.965 D/onProgressChanged( 8155): media seek new pos: 10164
Line 8609: 07-07 12:05:27.030 D/onProgressChanged( 8155): media seek new pos: 15400
Line 8635: 07-07 12:05:27.090 D/onProgressChanged( 8155): media seek new pos: 21375
Line 8649: 07-07 12:05:27.130 D/onProgressChanged( 8155): media seek new pos: 22730
Line 8663: 07-07 12:05:27.165 D/onProgressChanged( 8155): media seek new pos: 23346
Line 8677: 07-07 12:05:27.205 D/onProgressChanged( 8155): media seek new pos: 23777
Line 8725: 07-07 12:05:27.245 D/onProgressChanged( 8155): seekTo pos: 23777
Line 8727: 07-07 12:05:27.245 W/IJKMEDIA( 8155): IjkMediaPlayer_seekTo
Line 8729: 07-07 12:05:27.245 W/IJKMEDIA( 8155): ijkmp_seek_to(23777)
Line 8731: 07-07 12:05:27.245 W/IJKMEDIA( 8155): ijkmp_seek_to(23777)=0
Line 8733: 07-07 12:05:27.245 W/IJKMEDIA( 8155): ijkmp_get_msg: FFP_REQ_SEEK
Line 8735: 07-07 12:05:27.245 E/IJKMEDIA( 8155): stream_seek 23777000(23777) + 0, 
Line 8737: 07-07 12:05:27.245 D/IJKMEDIA( 8155): ijkmp_get_msg: FFP_REQ_SEEK: seek to 23777
Line 8737: 07-07 12:05:27.245 D/IJKMEDIA( 8155): ijkmp_get_msg: FFP_REQ_SEEK: seek to 23777
Line 8861: 07-07 12:05:27.690 W/IJKMEDIA( 8155): ijkmp_get_msg: FFP_MSG_SEEK_COMPLETE
Line 8999: 07-07 12:05:27.695 W/IJKMEDIA( 8155): FFP_MSG_SEEK_COMPLETE:
Line 9741: 07-07 12:05:27.715 D/tv.danmaku.ijk.media.widget.VideoView( 8155): onSeekComplete, pos: 7946

[bbcallen]

UI部分seekbar的回调处理得不太合理，如果放手很快，最后一个位置不会被传给播放器，建议自行修改。

[Android4MediaPlayer]

这个不是播放器内核问题，videoview相关你可以自己修改实现。

[wanzhang]

        if (mInstantSeeking) {
            mHandler.removeCallbacks(lastRunnable);
            lastRunnable = new Runnable() {
                @Override
                public void run() {
                    mPlayer.seekTo(newposition);
                }
            };
            mHandler.postDelayed(lastRunnable, 200);
        }

这段代码不是很明白，seekTo是发送命令，不怎么耗时，为什么要post到handler里面完成呢？并且延时200ms才去seek，请问一下这是基于什么考虑呢？ 我这边能够直接调用seekTo吗？

[myrao]

Here are my solution for this problem.
You can overwrite the system MediaController.java and modified the mSeekListener like this:

private OnSeekBarChangeListener mSeekListener=new OnSeekBarChangeListener(){
    long newposition;

    public void onStartTrackingTouch(SeekBar bar){
      show(3600000);
      mDragging=true;
      if(seekerBarDraggingListener!=null)
        seekerBarDraggingListener.getCurrentDraggingstatus(mDragging);

      // By removing these pending progress messages we make sure
      // that a) we won't update the progress while the user adjusts
      // the seekbar and b) once the user is done dragging the thumb
      // we will post one of these messages to the queue again and
      // this ensures that there will be exactly one message queued up.
      mHandler.removeMessages(SHOW_PROGRESS);
    }

    public void onProgressChanged(SeekBar bar,int progress,boolean fromuser){
      if(!fromuser){
        // We're not interested in programmatically generated changes to
        // the progress bar's position.
        return;
      }
      long duration=mPlayer.getDuration();
      newposition=(duration*progress)/1000L;
      // 系统原来的实现是在progress改变的时候时刻都在进行videoplayer的seek
      //这会导致seek m3u8切片文件的时候拖动seek时不准确，所以需要在拖动完成后才进行播放器的seekTo()
      //                mPlayer.seekTo((int) newposition);
      if(mCurrentTime!=null)
        mCurrentTime.setText(stringForTime((int)newposition));
    }

    public void onStopTrackingTouch(SeekBar bar){
      mDragging=false;
      mPlayer.seekTo((int)newposition);
      if(seekerBarDraggingListener!=null)
        seekerBarDraggingListener.getCurrentDraggingstatus(mDragging);
      setProgress();
      updatePausePlay();
      if(isntNeedStayShowAfterDrag){
        show(sDefaultTimeout);
        // Ensure that progress is properly updated in the future,
        // the call to show() does not guarantee this because it is a
        // no-op if we are already showing.
        mHandler.sendEmptyMessage(SHOW_PROGRESS);
      }
    }
  };

http://blog.csdn.net/zxccxzzxz

[androidliuzemin]

Here are my solution for this problem.
You can overwrite the system MediaController.java and modified the mSeekListener like this:
private OnSeekBarChangeListener mSeekListener=new OnSeekBarChangeListener(){
long newposition;

public void onStartTrackingTouch(SeekBar bar){
  show(3600000);
  mDragging=true;
  if(seekerBarDraggingListener!=null)
    seekerBarDraggingListener.getCurrentDraggingstatus(mDragging);

  // By removing these pending progress messages we make sure
  // that a) we won't update the progress while the user adjusts
  // the seekbar and b) once the user is done dragging the thumb
  // we will post one of these messages to the queue again and
  // this ensures that there will be exactly one message queued up.
  mHandler.removeMessages(SHOW_PROGRESS);
}

public void onProgressChanged(SeekBar bar,int progress,boolean fromuser){
  if(!fromuser){
    // We're not interested in programmatically generated changes to
    // the progress bar's position.
    return;
  }
  long duration=mPlayer.getDuration();
  newposition=(duration*progress)/1000L;
  // 系统原来的实现是在progress改变的时候时刻都在进行videoplayer的seek
  //这会导致seek m3u8切片文件的时候拖动seek时不准确，所以需要在拖动完成后才进行播放器的seekTo()
  //                mPlayer.seekTo((int) newposition);
  if(mCurrentTime!=null)
    mCurrentTime.setText(stringForTime((int)newposition));
}

public void onStopTrackingTouch(SeekBar bar){
  mDragging=false;
  mPlayer.seekTo((int)newposition);
  if(seekerBarDraggingListener!=null)
    seekerBarDraggingListener.getCurrentDraggingstatus(mDragging);
  setProgress();
  updatePausePlay();
  if(isntNeedStayShowAfterDrag){
    show(sDefaultTimeout);
    // Ensure that progress is properly updated in the future,
    // the call to show() does not guarantee this because it is a
    // no-op if we are already showing.
    mHandler.sendEmptyMessage(SHOW_PROGRESS);
  }
}

};
http://blog.csdn.net/zxccxzzxz

我试过了这种方式，还是有问题，而且，项目需求是拖动进度条的时候视频画面要跟着动，所以必须在change的时候一直seek

[myrao]

如果是这种需求那么得考虑一下如何寻找关键帧了, 而且和视频编码时的逻辑也有关系吧, 可以参考抖音和微信现在的视频裁剪功能看看, 两者应该直接用的 FFMpeg 处理了

[githubzhy]

没有开启精准seek吗？

[wanghuasheng]

看来这个播放器还有很多问题啊。