-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
M3U8分段视频在seekTo的时候需要很长时间才能播放,这时间跟拖动距离有关,怎样才能缩短时间? #2874
Comments
maybe you need modify the ffmpeg.make the probe size smaller. |
the default probe is 5s. too long |
使用IJKFFMoviePlayerController的话,我也碰到这问题,后来我直接改用IJKAVMoviePlayerController来显示,拖动进度就很快了,看了下IJKFFMoviePlayerController的日志,拖动的时候,会一个个ts请求下去,直到找到需要的ts,这样不慢才怪,不知道有什么法子直接定位到所需要的ts |
有sample url吗 |
IJKAVMoviePlayerController use the ios defalut mediaplayer. not ffplay. |
What's the prope size? Can it be modified when the video playing? I have both m3u8 and other video format like MP4. Is it will effect the MP4 playing?
发自网易邮箱大师
在2017年03月27日 10:23,test 写道:
IJKAVMoviePlayerController use the ios defalut mediaplayer. not ffplay.
if yout want use ffplay,pls use IJKFFMoviePlayerController.
when the play seek to position.Reduced the probe size make it fast.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Hi 0ct0cat, |
there is a member probesize in AVFormatContext ,you can set it's value to control the demuxer probe size. |
how to set probesize ,and where can i set it's value? |
just like this |
thank you |
I haved tried this, and i make pls->ctx->probesize = 4 * 1024. But it is not helpful. Does it work? |
Hi 0ct0cat, |
@drivedreams |
Why do the bilibili app not have this problem? Do you have any idea to resolve it?
发自网易邮箱大师
在2017年04月07日 16:13,test 写道:
@drivedreams
i test this stream,it's can't seek.
maybe there is a problem in mpegts.c.
after seek, hls.c work normal,it's can find right url to read and down ts data.
but the av_read_frame stop work.i think it's demux's bug.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@drivedreams |
Maybe sohu url is not standard. But vitamio player can play it without that problem? I can't modify sohu. It's aware |
@drivedreams 解决了么,我也遇到这个样的问题,怎么解决的? |
没有,可能需要更改源码,没时间研究。我查看搜狐的m m3u8格式应该是没有问题的。 |
@drivedreams 我本地文件也是这样的,不知道什么原因 |
Now, I test playing with IjkExoMediaPlayer. It can seek without the above problem. But I do not know whether it will cause any other problem. |
这个是因为视频源的dts时间戳远小于seek时间戳,导致一直在找合适的分片,可以在hls_read_packet中使用分片查找的方式解决该问题 |
@kandynan |
我现在这么该暂时还没有发现问题
在 2017-04-25 13:15:35,"ZhangHaihai" <notifications@github.com> 写道:
@kandynan
你的意思是修改ffmpeg源码重新编译吗,可以通过setoption之类的方法实现吗,不知道改动源码会不会导致其他问题。
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@kandynan |
问题还没解决,我把我最近几天的分析写出来,大家帮忙分析下:
|
等待后续结论 |
同等待 |
遇到这个问题主要是视频源里有#EXT-X-DISCONTINUITY这个标签,ffmpeg目前对这个标签是不支持的,可以参考:https://trac.ffmpeg.org/ticket/5419#comment:17 。如果使用官方原生的ffmpeg,带这个标签的视频是无法播放的。
并且在hls_read_packet函数中声明一个变量,来保存这个时长:
然后在hls_read_packet函数中的这段代码中插入这个函数的调用:
最后在计算seek的timestamp是否在当前packet的区间的代码上加上这个时长:
这样即可正确的seek,不会一直在这个循环中查询了。 |
@CloudIAU 感谢回复,最近一直忙别的项目没看视频。 有时间按照您的方法修改下。还有就是发现ios 研究起来方便些 因为方便调试 |
@CloudIAU 按照你的修改后Seek正常了 |
@raymond1012 是否应该把这个bug 上面的解决方案已经验证了 |
@raymond1012 是不是应该把上面的解决方案应用到源码中,这样可以关闭很多issue |
能提供下sample url吗 |
@Android4MediaPlayer 我提供的Url现在都是动态变化的。给你了也很快就会失效不具备代表性。这个BUG应该对于所有的点播的M3U8视频都都会出现,而且是必现的。随便找个M3U8测试下呗。 |
…ONTINUITY tag [why] FFmpeg doesn't support such tag handling for hls streaming. [how] Apply patch from bilibili#2874 reviewer: Todd_Chen
@CloudIAU 你好, 我按照你说的方案添加了以后(我将ffplay里边的几个hls.c都做了修改), 使用编译好的ijk播放视频的时候只要快进就崩溃.信息如下: |
@yeshibuzhong 是不是 seq_no >= pls->n_segments? |
@Android4MediaPlayer @CloudIAU
上面这段代码目的是为了在有 #EXT-X-DISCONTINUITY 修复pts,加上 previous_duration。
另外一个问题就是为什么要做这个判断 seq_no < pls->n_segments?
|
@drivedreams 你好, 我按照CloudIAU方法, 快进的时候回崩溃掉, 我用的是ijk0.88 最新版, 请问你知道怎么回事吗? |
@CloudIAU 大佬这段代码有pull 到源码上么 |
各位大佬,这个问题解决了吗,现在测试的情况来看,拖放的时候加载依然缓慢,比mp4格式的拖放要慢很多 |
@chenzh2017,一样的,遇到了,mp4播放不会慢,但是用么m3u8播放就会加长,让后循环播放不得行 |
你好,请问iOS上怎么解决这个问题 |
播放M3u8的视频的时候,最好: 其他的都是用默认配置就好,亲测有效,播放下载的M3u8视频 拖动进度, 效果挺好(大概1-2秒),没那么长的缓冲时间了 |
这是我用的M3U8地址:http://hot.vrs.sohu.com/ipad1479474_4601450223274_4680795.m3u8?plat=17&prod=ad
现象:1.播放整个的大视频seekTo时,没有问题,很快就可以继续播放。
2.对M3U8地址视频使用seekTo时可能出现两种情况:1.缓冲很长时间后可以播放 2.缓冲一段时间后视频暂停,点击播放视频从头开始播放。
3.如果seekTo的位置已经预缓冲完成则seekTo可以很快播放。
4.通过Log及播放信息可以看出,缓冲很长时间这个过程中,一直有数据进行下载,且速度并不慢。
请教各位大神帮忙分析下,这个问题很头疼,现在都是用这中分段的视频,缓冲时间过长太影响体验,谢谢了!
The text was updated successfully, but these errors were encountered: