Base64视频编码 - 是个好主意还是坏主意？

Question

Base64视频编码 - 是个好主意还是坏主意？

javascripthtmlcordovavideobase64

31

我正在使用cordova开发移动前端项目，与我合作的后端开发人员坚持认为媒体文件（图片/视频）应该在json文件中以base64编码传输。

目前来看，对于图片，它可以工作。虽然它会冻结UI几秒钟，但可以以某种方式推迟。

然而，处理视频迄今为止令人头疼，一个简单的视频的长度达到了近300,000。它会让我的可怜笔记本电脑旋转不停，在大约20秒的代码执行时间之后获取uri（并且仍然无法正常工作），并且每次刷新都几乎会使其崩溃，因此我不想调试它。

所以我的问题是：

在移动开发中，base64编码是传输媒体的普遍方式吗？
如果不是，您会推荐使用哪种替代方案来传输/呈现这些视频？

值得一提的是，这些视频是打算由大量人（也许是数百人）同时观看的，另一个开发人员说他们的服务器无法处理如此多的流量。

非常感谢任何建议，我找不到这个信息。

- Shay

从带宽和性能的角度来看，base64是传输视频的一种可怕方式，使用二进制可以避免解包开销。 - dandavis

为什么不利用提供（同时也是免费的）API的众多免费视频托管站点呢？YouTube？Vimeo？Flickr？Base64在这里行不通，对于移动客户端而言，数据量太大了，尤其是。 - Rob M.

感谢您的快速回答。我同意，这似乎是一种可怕的传输视频的方式。:) 这些视频应该只针对员工，因此他们希望限制他们对这些视频的访问。还有哪些其他可能的选择呢？谢谢！ - Shay

你可以在内部网络的某个需要登录的页面上提供MP4文件，或者为视频文件本身使用基本认证方式，即使是通过Apache也可以实现。 - dandavis

当然，这是最简单的方法，我希望他们能采用这种方式，但他们不想过载服务器上的流量... 这有意义吗？还是Base64实际上会增加流量？（因为传输的文件大小更大） - Shay

https://medium.com/@alexcambose/webcam-live-streaming-with-websockets-and-base64-64b1b4992db8 - quarks

4个回答

23

“33%的开销”为何总被提及，这完全是胡说八道。是的，一开始会增加大约这么多，但有一个叫gzip（你听说过吗？）的小东西存在。我做了很多测试，差异通常可以忽略不计。实际上，有时候经过gzipped base64编码的字符串比二进制文件还要小。看看这位先生的测试。所以，请不要再传播绝对的虚构。

Base64是检索视频的完全可接受的方法。实际上，它对于私人消息系统非常有效。例如，如果您正在使用AWS S3，您可以将文件存储为私有文件，因此没有URL。

然而，使用gzipped base64视频的主要缺点（我的看法）是您需要等待整个视频加载完成，因此伪流无法实现。

- D-Marc

3

如果将视频分成多个块，例如实时视频会议客户端 Web 应用程序可以捕获约 50KB 的视频块，然后对其进行 Base64 编码和 gzip 压缩，那么 Web 服务器可以将已压缩的 base64 图像广播给消费者/客户端。这种方法对于 Base64 是否有效？ - quarks

2

Base64是一种方便（但效率不高）的二进制数据传输方式。它的效率不高，因为传输大小会比原来传输的数据大33％。所以它不是传输视频的流行方式。如果您计划流式传输该视频，则应寻找已建立的协议来完成此操作。我建议使用流媒体协议（有很多可以选择）。

- Pablo Santa Cruz

谢谢你的建议，我会去查一下的。 :) - Shay

1

我认为这是个不好的主意，视频文件太大了。但你可以尝试使用小视频文件。尝试在线编码器 https://base64.online/encoders/encode-video-to-base64 在那里，你可以将视频转换为Base64数据URI，并尝试插入到HTML中。结果看起来像这样：

<video controls><source src="data:video/mpeg;base64,AAABuiEAAQALgBexAAABuwAMgBexBeH/wMAg4ODgAAA..."></video>

- Denys Sokolov

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- user1693593 · Accepted Answer

[...] 后端开发人员 [...] 坚持认为媒体文件（图片/视频）应该作为 base64 编码的 json 文件传输。

这是一个非常糟糕（而且愚蠢）的想法。您不希望将大量二进制数据作为字符串传输，尤其不是 Unicode 字符串。

在这里，您需要武装起来，用任何手段说服您的后端开发人员改变他的想法，播放一些 Biber 或 Nickelback，甚至将他的背景图像更改为 Hello Kitty 的某些东西，或者拍摄他的屏幕截图，将其设置为背景并隐藏所有图标和栏。这应该有助于改变他的想法。如果没有，请在他的办公室安装 webasto 并锁定所有门窗。

base64 编码是移动开发中传输媒体的流行方式吗？

它很受欢迎，并且具有相对较长的历史，在 Usenet 等地方变得非常普遍。然而，在那些日子里，数据量与今天相比非常低，因为所有数据都通过调制解调器传输。

但是，仅因为它很受欢迎并不意味着它是万能的工具。它不太高效，因为它需要一个编码过程，将三个八位组转换为四个字节，导致大小增加了33％。

此外：在JavaScript中，每个字符串字符由于Unicode字符集而以两个字节存储，因此您的数据会增加一倍并扩展33%。您的300 MB数据现在变成了300 x 2 x 1.33 = 798 MB（向您的后端开发人员展示这个！ :) 因为如果服务器无法处理大量流量，这是一个真实的因素）。

对于较小的文件，这种方法效果不错，但对于像您的示例中那样的较大文件，这可能会导致时间和内存使用方面的显着开销，当然还有带宽。当然，在服务器端，您需要使用自己的开销来反转这个过程。

“如果不行，您会推荐使用哪种替代方式来传输/呈现这些视频？”

我建议：

- 将元数据单独作为JSON，并使用对数据的“引用”。 JSON中不包含二进制数据。 - 将媒体数据本身分别以“原生字节”（ArrayBuffer）的形式传输。 - 同时将两者发送到服务器。 - 然后，服务器只需将JSON数据解析为后端可用的格式，二进制数据可以直接写入磁盘。

更新：我忘记提到，正如Pablo在他的答案中所提到的，您可以考虑流式传输数据。

然而，流媒体与缓冲几乎是同义词，所以带宽基本相同，只是以一种更加强力的方式提供（通常是UDP与TCP之间的区别，即数据包的丢失不会中断传输）。但是，与客户端缓冲相比，流媒体会限制您的选择。

这只是我的个人观点...