向前拖动,进度条会往回跳 #313

Closed
wanzhang opened this Issue Jul 7, 2015 · 6 comments

Projects

None yet

4 participants

@wanzhang
wanzhang commented Jul 7, 2015

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

@wanzhang
wanzhang commented Jul 7, 2015

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

@wanzhang
wanzhang commented Jul 7, 2015
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
Member
bbcallen commented Jul 8, 2015

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

@Android4MediaPlayer

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

@wanzhang
wanzhang commented Jul 8, 2015
        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吗?

@bbcallen bbcallen added the staled label Dec 18, 2015
@bbcallen bbcallen closed this Dec 18, 2015
@eterrao
eterrao commented Nov 9, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment