什么时候视频文件太大而无法流式传输/多播？

Question

我目前正在开发一个使用Java和Spring MVC的服务，用户可以上传视频文件。这些可以在以后通过我们的API检索。

当视频文件通过我们的API加载时，我们只是完整地发送文件，作为下载，没有流式传输或多播。我知道这只适用于你达到一定的文件大小。任何人都有关于最大文件大小应该是什么的建议？即我们应该从哪个文件大小开始使用视频流服务？

Answer 1

这实际上是一个相当复杂的问题，因为需要考虑多个因素。我将列出每种方法的优点和缺点，并最终提供一种替代解决方案。

下载/上传整个文件一次：

- >赞成： 易于编程

- >缺点： 作为一个用户试图上传两人很快千兆字节文件，在将文件保存到文件系统或保存到文件系统的任何位置之前，该文件将存储在服务器的内存中。你可以想象有100个用户这样做，你的服务器就会崩溃。您可以在servlet容器级别限制请求的大小，但是这会限制您的用户。另一种方法是在应用程序级别限制它，但仍然限制用户。几年前，tomcat的上传默认大小为2097152（2 megs）。不知道它现在有多少，但即使你将它撞到10mb或100mb，然后你运行我所描述的问题：当多个用户尝试上传大文件时，你将它们放在内存中。

下载/上传使用流

文件 - >赞成： 流将不要求所有的内容在保存前存在于内存中。这是一种更优雅的方式，在所有方面都比发送一切更好。此外，您可能会绕过企业环境中的大多数问题，如发送大文件，防火墙，servlet容器限制等。

此外，如果您使用进度条实现流式传输，则向系统发送大文件的用户不会认为它坠毁，这将显着改善您的用户体验。

- >缺点： 不是很多，但稍微难以实施。像普通的IOUtils这样的图书馆，在实施流媒体解决方案时不应该有任何问题。如你所见，无论文件的大小如何，在大多数情况下，流式传输文件的内容会更好，但如果你仍想使用整个文件解决方案，那么你可以使用10MB的限制或者区。这取决于您希望视频的大小。

需要注意的一件事是，如果您还想使用流式传输功能来允许用户查看视频内容，那么您不必为其servlet容器加载不应该做的事情：流式传输视频。 Servlet容器用于回答http请求，并且通过池的设计进行设计，以重用期待短暂HTTP请求的线程。在某个时候，http servlet容器不适合流式传输视频和同时提供http请求。一个可能的解决方案可能是您的用户使用您的api将您的文件上传到视频服务器，然后使用甚至可能位于不同位置的视频服务器将视频流式传输回用户。你可以看看这个：http：//www.red5.org/

你可以从这个设置得到什么是： - >你减轻了你的HTTP服务器的负载，你用它来它意味着什么：提供HTTP请求 - >您可以减少应用程序的复杂性，因为流媒体，播放等内容不是由您的应用程序处理，而是由视频服务器处理。