有人遇到过这个错误吗? RTMP 流媒体视频提前 3-4 秒结束?
我过去为客户创建了一个播放器,使用他们的 LimeLight 服务器来流式传输视频,之前没有遇到过问题,但是对于使用不同 LimeLight 服务器的新客户来说,视频似乎提前结束了 3-4 秒。
我测试了 3 个截然不同的视频的痕迹:
metadata duration = 32 // 32 secs long, ends at 27
Stop [27.350 seconds] = 4.65
metadata duration = 17 // 17 secs long, ends at 12
Stop [12.852 seconds] = 4.148
metadata duration = 258 // 258 secs long, ends at 255
Stop [255.861 seconds]
在视频播放器中,我检查 NetStream.Play.Stop,然后在其中放置一个“重置”类型的函数。然而,由于这个奇怪的错误,这个函数触发得太早了。 以前有人见过这个吗?
private function netStatusHandler(event:NetStatusEvent):void
{
trace("connected is: " + nc.connected );
switch (event.info.code)
{
case "NetConnection.Connect.Success":
trace("Connected");
connectStream();
break;
case "NetStream.Play.Start":
trace("********** Start [" + ns.time.toFixed(3) + " seconds]");
break;
case "NetStream.Play.Stop":
trace("‹ ----------- Playback has stopped. ----------- ›");
trace("Stop [" + ns.time.toFixed(3) + " seconds]");
if (nsBuffering){ removeChild(bufferAni); }
nsBuffering = false;
videoStatus = "NotPlaying";
resetVideo(); //<- Video ends so go back to start
// ^ This triggers too early
break;
}
}
我看到的唯一解决方法是保存从元数据持续时间中获得的初始数字,并运行一个计时器来不断检查当前 ns.time 何时匹配元数据,然后运行我的重置功能。
I've created a player for a client in the past using their LimeLight server to stream videos and not had an issue before, however for a new client using different LimeLight server, the videos seem to be ending 3-4 secs too early.
My traces on 3 vastly different videos I tested:
metadata duration = 32 // 32 secs long, ends at 27
Stop [27.350 seconds] = 4.65
metadata duration = 17 // 17 secs long, ends at 12
Stop [12.852 seconds] = 4.148
metadata duration = 258 // 258 secs long, ends at 255
Stop [255.861 seconds]
In the video players I check for NetStream.Play.Stop
then put a 'reset' type function in there. This function however triggers too early due to this strange bug. Has anyone have seen this before?
private function netStatusHandler(event:NetStatusEvent):void
{
trace("connected is: " + nc.connected );
switch (event.info.code)
{
case "NetConnection.Connect.Success":
trace("Connected");
connectStream();
break;
case "NetStream.Play.Start":
trace("********** Start [" + ns.time.toFixed(3) + " seconds]");
break;
case "NetStream.Play.Stop":
trace("‹ ----------- Playback has stopped. ----------- ›");
trace("Stop [" + ns.time.toFixed(3) + " seconds]");
if (nsBuffering){ removeChild(bufferAni); }
nsBuffering = false;
videoStatus = "NotPlaying";
resetVideo(); //<- Video ends so go back to start
// ^ This triggers too early
break;
}
}
The only work-around I see for this is saving the initial number I get from the metadata duration, and running a timer to constantly check for when the current ns.time matches metadata and then run my reset function.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我找到了解决办法!
http://www.wildform.com/support/tutorials/loopingFLVs/
我有当网络流点击 play.stop 时首先进行检查,然后在缓冲区为空时调用我的重置函数...
网站上的代码是 AS2,但我将其转换为 AS3:
。
I FOUND THE FIX!
http://www.wildform.com/support/tutorials/loopingFLVs/
I had to put in a check first when the netstream hit play.stop, then call my reset function when the buffer was empty...
The code on the site is AS2, but I converted it to AS3:
.
我知道这个帖子非常老了,但我一直在绞尽脑汁试图解决这个问题;除了您的解决方案之外,网上没有太多关于它的信息。
所以,我已经弄清楚了。如果您使用 rtmp,您需要将 bufferTime 更改为 false。
由于 rtmp 不缓存,因此不需要缓冲时间,如果您设置一个,您就会限制自己,最终缓冲区将是空的。
I know this thread is incredibly old, but I was banging my head trying to resolve this issue; and aside from your solution, there just isn't much about it online.
So, I've figured it out. If you are using rtmp, you need to change bufferTime to false.
Since rtmp DOES NOT cache, there is no need for buffer time, and if you set one, you are limiting yourself and eventually the buffer will be empty.