Flex/Flash 完全缓冲 Wowza 的 rtmp 流

发布于 2024-12-09 16:16:59 字数 1228 浏览 0 评论 0原文

我在尝试使用内部 Flash 播放器完全缓冲 Wowza 媒体服务器上预先录制的 rtmp 流时遇到了一些麻烦。完全预缓冲视频的要求来自管理层。必须可以离线观看整个视频。

当 netConnection 对象获得连接时，我创建 NetStream 对象，为其设置一个元数据事件处理程序，将 NetStream.maxBufferTime 设置为视频的完整持续时间。另外，在创建 NetStream 时，我向视频组件添加了一个 Event.ENTER_FRAME 侦听器，以便它检查视频何时加载（它有宽度），以便它会在第一帧暂停。

然后我开始播放网络流中的视频。当接收到元数据事件时，缓冲区被设置，当第一帧被下载并显示在视频对象上时，播放器在第一帧上暂停，但继续将视频加载到缓冲区中。现在，当我跟踪缓冲区（NetStream.bufferLength）时，我注意到以下现象，这对我来说是一个主要的悲伤来源：

如果 NetStream.maxBufferTime 设置为视频长度的 100%，则视频将完全缓冲，然后大约四秒后，播放头（NetStream.time）移至视频末尾。然而，当我在 Linux 系统上恢复播放时，视频正常显示，但播放头保持在 100%（这对自定义提示点处理造成严重破坏）。在 Windows 系统上，播放头也保持在 100%，但视频以正常速度的 100 倍播放。

当缓冲区达到 100% 时，会触发 NetStream.buffer.flush 和 NetStream.play.stop(?!?!) 事件，但播放器对它们都没有反应，所以对我来说，这似乎是闪存中的错误NetStream 或 Wowza。

但是，如果我将 NetStream.maxBufferTime 设置为（视频长度 - 0.4），缓冲将在流结束之前停止，并且 NetStream.Play.stop 不会被触发，并且播放头停留在第一帧，但这感觉有点太老套的解决方案。

渐进式下载感觉也不是一个解决方案，因为至少有一些（如果不是全部）视频必须至少在一定程度上受到保护以防止复制。

有什么指点吗？

Wowza 是 2.something，flex 是 4.1 以支持 flash 10.1，流要么用 flex/flash 记录器记录，要么上传到服务器并转换为 h.264（两者都表现出这种行为。）并且 flash 版本范围从 10.1 开始到 11.0。

编辑：看来我们在这个问题上采取的最终路径是，任何需要保护的视频都将作为 rtmp 流提供，缓冲最少，公共视频将作为渐进式下载服务器。正如评论中提到的，rtmp 不应该做缓冲，所以我们所做的基本上是错误的。供将来参考：不要缓冲超过几秒的 rtmp 流。

原文

I'm having a bit of trouble trying to fully buffer a pre-recorded rtmp-stream from Wowza media server with an in-house flash player. The requirement to fully pre-buffer the video comes from the management. It must be possible to view the whole video offline.

When the netConnection object gets a connection I create the NetStream object, set a metadata event handler for it that sets the NetStream.maxBufferTime to the full duration of the video. Also when creating the NetStream I add an Event.ENTER_FRAME listener to the video component so it checks when the video has been loaded(it has a width) so it will pause on the first frame.

Then I start playing the video from the netstream. When the metadata event is received the buffer is set, when the first frame is downloaded and displayed on the video object the player pauses on the first frame, but continues loading the video in the buffer. Now when I trace the buffer(NetStream.bufferLength) I notice the following phenomena which is a source of major grief for me:

If the NetStream.maxBufferTime is set to 100% of the length of the video, the video is buffered fully and after approximately four seconds pass the playhead(NetStream.time) gets moved to the end of the video. However when I resume the playback on a Linux system the video is displayed normally, but the playhead stays at 100%(Which wreaks havoc on custom cuepoint handling). On windows system the playhead also stays at 100% but the video is played back at 100x the speed of normal.

When the buffer reaches 100% the events NetStream.buffer.flush and NetStream.play.stop(?!?!) are triggered, but the player does react to neither of them, so to me it seems this is a bug in the flash NetStream or Wowza.

If however I set the NetStream.maxBufferTime to (the length of video - 0.4) the buffering stops just before the end of the stream and the NetStream.Play.stop doesn't get triggered and the playhead stays at the first frame, but this feels a bit too hackish solution.

Progressive download doesn't feel like a solution either, as at least some, if not all of the videos must be at least somewhat protected from copying.

Any pointers?

The Wowza is 2.something, flex is 4.1 to support flash 10.1, the streams are either recorded with a flex/flash recorder or uploaded to the server and converted to h.264(Both exhibit this behaviour.) and flash version range from 10.1 to 11.0.

Edit: It seems that the ultimate path we will take on this issue will be that any video that needs to be protected will be served as rtmp stream with minimal buffering and public videos will be server as progressive download. As it was mentioned in the comments rtmp is not supposed to do buffering, so what we were doing was basically wrong. For future reference: Do not buffer more than a few seconds of rtmp stream.

分享到QQ

分享到微博