漏洞？ Netstream 在初始暂停然后搜索后不会恢复
我遇到了一些奇怪的行为，我找不到任何记录 知识。
发生的情况如下：
调用 play() 方法后，当 NetStatus 代码出现时，网络流将暂停 是“NetStream.Play.Start”。这会自动禁用默认行为 玩。在使用togglePause()或resume()恢复之前，执行一次搜索 手术。当您尝试使用togglePause() 或resume() 恢复时， netstream 将不会再次开始播放。
如果你只是立即暂停（）然后恢复（）而中间没有seek（），它 恢复正常。
另外，如果将初始暂停延迟大约 250 毫秒，则可以使用eek() 和 随后resume() 没有问题。
我在这里发布了一个演示和源代码： http://drinkspiller.cannonballinteractive.com/temp/ResumeAfterPauseAndSeek/
代码是示例直接从 NetStream 的 AS3 文档中编写代码，并带有较小的 添加了处理初始暂停以及处理搜索和恢复按钮的功能。 没什么好说的。
请注意，我通过调用stream.seek(0)然后调用stream.pause();来暂停。这 确保第一帧显示在 Video 实例中，而不是不显示任何内容。相同 行为发生在没有stream.seek(0)并且仅使用stream.pause()停止的情况下 播放。
我还尝试过延迟对 startPaused(); 的调用直到缓冲区满事件 代码，但行为是相同的。
任何人都可以帮我找到一个合理的解决方法或为我确认这是一个 漏洞？非常感谢！
I'm experiencing some strange behavior for which I can't find any documented
knowledge.
Here's what is happening:
After calling the play() method, a netstream is paused when the NetStatus code
is "NetStream.Play.Start". This disables the default behavior of automatically
playing. Before resuming with either togglePause() OR resume(), perform a seek
operation. When you attempt to resume with togglePause() or resume(), the
netstream will not start playing again.
If you just immediately pause() then resume() without a seek() in between, it
resumes fine.
Also, if you delay the initial pause by about 250ms, you can then seek() and
subsequently resume() with no problems.
I posted a demo and source here:
http://drinkspiller.cannonballinteractive.com/temp/ResumeAfterPauseAndSeek/
The code is the example code directly from the AS3 docs for NetStream with minor
additions to handle the initial pause and handle the seek and resume buttons.
There's not much to it.
Note that I am pausing by calling stream.seek(0) then stream.pause(); This
ensures the first frame shows in the Video instance instead of nothing. The same
behavior occurs without stream.seek(0) and only using stream.pause() to stop
playback.
I've also tried delaying the call to startPaused(); until the buffer full event
code but the behavior is the same.
Can anyone help me find a sensible workaround or confirm for me that this is a
bug? Many thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
肯定存在一些错误（以及一些糟糕的文档）。但是，我认为您的示例存在两个潜在问题：
我认为在接收有关 FLV 的元数据之前调用 NetStream.seek 不是一个好主意。 （考虑持续时间是从元数据中提取的）。我不知道是否有相关的官方文档，但我根据经验发现这可能会出现问题。您可以尝试将任何暂停/搜索事件放入 onMetaData 事件处理程序中。
我的有限理解是元数据包含在 FLV 数据中。它可以位于任何地方，但理想情况下，通常情况下，它位于文件的前面。因此，在逐步下载时，NetStream 必须接收足够的信息来获取对视频执行更高级操作（例如查找）所需的元数据。这可以解释为什么它在 250 毫秒的暂停时对你有效。
您的示例 FLV 的编码方式与我使用过的其他 FLV 不同。我不太清楚为什么，但如果我更改为引用不同的 FLV，一切都会很好（在问题 #1 得到解决之后）。
我认为您的示例 FLV 可能只是缺少搜索所需的关键帧。我尝试重新编码以包含关键帧，但它仍然不起作用。我不太确定该 FLV 有什么不同，如果有人能指出这一点，我会发现它也非常有用。
关于使用eek(0)调用来确保有海报框架......我自己不必这样做。这也可能与 FLV 的编码方式有关。
There are definitely some bugs at play (and some poor documentation). But, I think there are two potential issues with your sample:
I don't think it's a good idea to call NetStream.seek before receiving metadata about the FLV. (Consider that duration is extracted from the metadata). I don't know if there's official documentation about that, but I've found from experience it can be problematic. You might try putting any pause/seek events in the onMetaData event handler.
My limited understanding is that metadata is included inline with the FLV data. It can be anywhere, but ideally and usually, it's at the front of the file. So when progressively downloading, the NetStream must receive enough information to get the metadata it needs to do more advanced things with the video (like seeking). That could explain why it worked for you when putting in a 250ms pause.
Your sample FLV is encoded differently from other FLVs I've worked with. I'm not exactly sure why, but if I changed to reference a different FLV, everything worked great (after issue #1 was addressed that is.)
I thought maybe your sample FLV was just missing keyframes, which are required for seeking. I tried reencoding to include keyframes and it still didn't work though. I'm not really sure what's different about that FLV, and if anyone can point that out, I'd find it very useful too.
Regarding using a seek(0) call to make sure there's a poster frame... I haven't had to do that myself. This could also be related to how FLVs are encoded though.
如果你执行 netstream.seek(0);它再次调用您的元数据处理程序。
If you do a netstream.seek(0); it calls your metadata handler again.