Red5的视频录制质量很糟糕

发布于 2024-10-19 11:59:01 字数 560 浏览 1 评论 0原文

我在运行 Linux 的 EC2 上安装了 Red5 1.0。我的目标是从我的网站录制网络摄像头视频 - 连接到用户的网络摄像头并将视频保存到 S3。

我在预安装的演示应用程序中尝试了录像机应用程序。它可以工作,但是当我播放录制的 flv 视频时,质量很糟糕。

  • 最好的情况是,视频极度像素化并且随着运动而变得模糊
  • 。最坏的情况是,视频甚至无法播放——它只是停留在一帧上。
  • 最常见的是,视频和音频完全不同步并且断断续续。我发现我可以通过使用配置文件之一增加服务器上的缓冲区限额来影响这一点,但增加缓冲区似乎会导致视频变得不稳定。

我尝试过连接多台计算机,甚至是快速的公司互联网连接。有趣的是,即使连接到本地主机,质量问题仍然存在,因此这似乎不是网络问题。

当我使用 red5-recorder.com flash 应用程序录制到演示服务器应用程序时,质量更差。

最终,我只想从访客的网络摄像头获得高质量的视频录制,但不想花钱购买 FMS 或 Wowza。

关于如何让 Red5 录制高质量的任何想法?总是这么糟糕吗?

感谢您的帮助!!

I installed Red5 1.0 on EC2 running linux. My goal is to record webcam video from my website -- connect to a user's webcam and save the video to S3.

I tried out the video recorder application in the pre-installed demo apps. It works, but when I play back the recorded flv video, the quality is terrible.

  • At best, the video is extremely pixelated and blurs with motion
  • At worst, the video doesn't even play -- it just stays stuck on one frame
  • Most often, the video and audio are totally out of sync and choppy. I found that I could affect this be increasing the buffer allowance on the server using one of the config files, but increasing the buffer seems to cause the video to get choppy.

I've tried connecting with multiple computers and even a fast corporate internet connection. Interestingly, the quality issues persist even when connecting to localhost, so it doesn't seem to be a network problem.

When I use the red5-recorder.com flash app to record to the demo server app, the quality is even worse.

Ultimately, I just want to get a high quality video recording from a visitor's webcam, but don't want to drop the money for FMS or Wowza.

Any ideas on how to get Red5 to record high quality? Is it always this bad?

Thanks for your help!!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

温馨耳语 2024-10-26 11:59:01

录制视频的质量与 RED5 设置无关,而是与 Flash 应用程序设置有关。只需尝试设置 相机.setQuality() 为更适合您需求的内容。例如,如果您使用 setQuality(0, 100),您将获得最佳的视频质量,但带宽使用也会增加。

The quality of recorded video is not related with RED5 settings but your flash app settings. Just try to set Camera.setQuality() to something more suitable to your needs. For example if you use setQuality(0, 100) you'll get the best possible video quality but bandwidth use also increase.

安稳善良 2024-10-26 11:59:01

我们在 0.91 版本中遇到了同样的问题。我在某处读到过 0.8 就可以了。你可以试试那个..

We experience the same problem with 0.91 version. I read somewhere that 0.8 was fine. You might try that one..

半窗疏影 2024-10-26 11:59:01

尝试使用 Red5 RC1 它肯定会给你更好的录音,但我也在尝试找到更好的东西,直到现在我还没有想出一些东西..如果你解决了你的问题,我会很高兴听到更好的方法..

Try using Red5 RC1 it will surely give you much better recording but i am also trying to find something even better and i have not come up with something till now..if you solved your problem i would be glad to hear a better approach..

友欢 2024-10-26 11:59:01

所有 Red5 版本(1.0.2 及之前)都受到严重的视频录制问题的困扰。有关所有版本及其问题的列表,请参阅此答案

Red5 1.0.3 是 Red5 的第一个版本,修复了视频录制过程,因为它是第一个包含 这个很棒的补丁

快速解释两部分原因

Flash Player 缓冲(仅)视频数据包

当网络条件不允许同时发送音频数据包时,Flash Player 会缓冲视频数据包并仅发送音频数据包。

这对于您希望至少保持音频的实时视频场景非常有效,但不适用于本地缓冲的视频数据包最终太晚到达媒体服务器的视频录制场景(相应的 .flv 部分可能已经被写入)到磁盘)。

这就是为什么 AMS 和 Wowza 实现了延迟写入机制,在将数据写入磁盘之前等待视频数据包到达。

Red5 的 bug

Red5 也有这样的机制,但是由于一个严重的 bug,它正在丢弃视频数据包而不是等待它们。

该错误已通过上述补丁修复。

Red5 等待缓冲视频数据包的时间由 conf/red5.properties 中的 fileconsumer.queue.size 控制。默认值为 120,对于 2 分钟的高清视频缓冲来说应该足够了。

进一步阅读

All Red5 versions (up to and including 1.0.2 ) have been plagued by serious video recording issues. See this answer for a list of all versions and their issues.

Red5 1.0.3 is the 1st version of Red5 with the video recording process fixed because it's the 1st to contain this awesome patch.

Quick explanation of the 2 part cause

Flash Player buffering (only) video packets

Flash Player is known to buffer video packets and send only audio packets when the network conditions do not allow it to send both.

This works very well for live video scenarios where you want to keep at least the audio going but NOT for video recording scenarios where the locally buffered video packets end up arriving too late at the media server (the corresponding .flv section might have already been written to disk).

That's why AMS and Wowza have implemented delayed write mechanism where they wait for the video packets to arrive before writing the data to disk.

Red5's bug

Red5 also had such a mechanism but, due to a serious bug, it was dropping the video packets instead waiting for them.

The bug fas fixed with the patch mentioned above.

How much Red5 will wait for buffered video packets is controlled by fileconsumer.queue.size in conf/red5.properties. it defaults to 120 which should be enough for a buffer of 2 minutes of HD video.

Further reading

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文