javascript Base64 视频编码 - 好\坏主意？

Base64 video encoding - good\bad idea?

提问by Shay

I'm working on a mobile front-end project using cordova, and the backend developer i'm working with insists that the media files (images/videos) should be transferred as base64 encoded in json files.

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

Now, with images it's so far working. Although it freezes the UI for a few seconds, it can be deferred somehow.

现在，有了图像，它就可以工作了。虽然它会冻结 UI 几秒钟，但它可以以某种方式推迟。

The videos however are so far a pain to handle, the length of a single/simple video being transferred is nearly 300,000 in length. It brings my poor laptop through a wild spin, and gets the uri after about 20 seconds of going through the code (and it still not working, and I don't feel like debugging it cause it nearly crashes my laptop with every refresh).

然而，到目前为止，视频处理起来很麻烦，传输的单个/简单视频的长度接近 300,000。它让我可怜的笔记本电脑疯狂旋转，并在大约 20 秒的代码完成后获取 uri（但它仍然无法正常工作，我不想调试它，因为每次刷新时它几乎使我的笔记本电脑崩溃）。

So my questions are:

所以我的问题是：

• Is base64 encoding a popular way of transferring media in mobile development?
• And if not, what alternative way would you recommend using to transfer/present these videos?

• base64 编码是移动开发中传输媒体的流行方式吗？
• 如果没有，您建议使用什么替代方式来传输/呈现这些视频？

I should mention though, the videos are meant to be viewed at once by a large number of people (hundreds perhaps), and the other developer says that their servers can't handle such traffic.

不过我应该提一下，这些视频是为了让很多人（可能有数百人）同时观看，而另一位开发人员说他们的服务器无法处理这样的流量。

Much thanks for any advice, I couldn't find this info nowhere. :)

非常感谢您的任何建议，我无法在任何地方找到此信息。:)

采纳答案by Shay

[...] the backend developer [...] insists that the media files (images/videos) should be transferred as base64 encoded in json files.

[...] 后端开发人员 [...] 坚持媒体文件（图像/视频）应以 json 文件中的 base64 编码进行传输。

This is a very bad (and silly) idea up-front. You do notwant to transfer large amount of binary data as strings. Especially not Unicode strings.

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

Here you need to arm up and convince your backend dev rebel to change his mind with what-ever it takes, play some Biber or Nickelback, or even change his background image to something Hello Kitty, or take a snapshot of his screen, set it as background and hide all the icons and the bar. This should help you changing his mind. If not, place a webasto in his office at max and lock all doors and windows.

在这里，您需要武装起来并说服您的后端开发叛逆者改变主意，不惜一切代价，玩一些 Biber 或 Nickelback，甚至将他的背景图像更改为 Hello Kitty，或者拍摄他的屏幕快照，设置它作为背景并隐藏所有图标和栏。这应该有助于你改变他的想法。如果没有，请将 webasto 放在他的办公室，并锁上所有门窗。

Is base64 encoding a popular way of transferring media in mobile development?

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

It is popular and has a relative long history and became very common on Usenet and so forth. In those days however, the data amount was very low compared to today as all data where transferred over modems.

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

However, just because it is popular doesn't mean it is the right tool for everything. It is not very efficient as it require an encoding process which convert three octets into four bytes, causing an addition of 33% to the size.

然而，仅仅因为它很受欢迎并不意味着它是适合所有事情的工具。它不是很有效，因为它需要一个将三个八位字节转换为四个字节的编码过程，导致大小增加 33%。

On top of that: in JavaScript each string char is stored as two bytes due to Unicode char-set so your data is doubled and extended 33%. Your 300 mb data is now 300 x 2 x 1.33 = 798 mb (show that to your backdev! :) as it's a real factor if the servers cannot handle large amount of traffic).

最重要的是：在 JavaScript 中，由于 Unicode 字符集，每个字符串字符都存储为两个字节，因此您的数据翻倍并扩展了 33%。您的 300 mb 数据现在是 300 x 2 x 1.33 = 798 mb（向您的后台开发人员展示！:) 因为如果服务器无法处理大量流量，这是一个真正的因素）。

This works fine for smaller files but for larger file as in your example this can cause a significant overhead in both time and memory usage, and of course bandwidth. And of course, on server side you would need to reverse the process with its own overhead.

这适用于较小的文件，但对于较大的文件，如您的示例中所示，这可能会导致时间和内存使用量以及带宽的显着开销。当然，在服务器端，你需要用它自己的开销来逆转这个过程。

And if not, what alternative way would you recommend using to transfer/present these videos?

如果没有，您建议使用什么替代方式来传输/呈现这些视频？

I would recommend:

我会推荐：

• Separate meta-data out as JSON with a referenceto the data. No binary data in the JSON.
• Transfer the media data itself separately in native bytes(ArrayBuffer).
• Send both at the same time to server.

• 将元数据分离为 JSON，并引用数据。JSON 中没有二进制数据。
• 以本机字节(ArrayBuffer)单独传输媒体数据本身。
• 同时将两者发送到服务器。

The server then only need to parse the JSON data into edible for the backend, the binary data can go straight to disk.

然后服务器只需要将 JSON 数据解析为后端可食用的，二进制数据就可以直接上磁盘。

UpdateI forgot to mention, as Pablo does in his answer, that you can look into streaming the data.

更新我忘了提及，正如 Pablo 在他的回答中所做的那样，您可以查看数据流。

However, streaming is pretty much a synonym with buffering so the bandwidthwill be about the same, just provided in a more brute-force way (usually UDP versus TCP, ie. loss of packets doesn't break the transfer). Streaming with limit your options more than buffering in the client though.

然而，流几乎是缓冲的同义词，因此带宽将大致相同，只是以更暴力的方式提供（通常是 UDP 与 TCP，即数据包丢失不会中断传输）。但是，与在客户端进行缓冲相比，流式传输限制了您的选择。

My 2 cents...

我的 2 美分...

回答by D-Marc

Not sure why "33% overhead" is always mentioned, when that's complete nonsense. Yes, it does initially roughly add that amount, however there's a little thing called gzip (ever heard of it?). I've done tons of tests and the difference is typically negligible. In fact, sometimes the gzipped base64 string is actually smallerthan the binary file. Check out this guy's tests. So please, can we stop spreading absolute fiction.

不知道为什么总是提到“33% 的开销”，这完全是胡说八道。是的，它最初确实大致增加了这个数量，但是有一个叫做 gzip 的小东西（听说过吗？）。我已经做了大量的测试，差异通常可以忽略不计。事实上，有时gzip压缩的base64字符串实际上是小比二进制文件。看看这家伙的测试。所以拜托，我们能不能停止传播绝对的小说。

Base64 is a perfectly acceptable method of retrieving a video. In fact, it works amazing for a private messaging system. For instance, if you were using AWS S3, you could store the files privately so there is no URL.

Base64 是一种完全可以接受的检索视频的方法。事实上，它对于私人消息传递系统来说效果非常好。例如，如果您使用的是 AWS S3，您可以私下存储文件，因此没有 URL。

However, the main disadvantage (imho) of using a gzipped base64 video is that you need to wait for the whole video to load, so pseudo-streaming is out of the question.

但是，使用 gzip 压缩的 base64 视频的主要缺点 (imho) 是您需要等待整个视频加载，因此伪流是不可能的。

回答by Pablo Santa Cruz

Base64is a convenient (but not efficient) way of transferring binary data. It's inefficient because transfer size will be 33% bigger than what you're originally transferring. Si it's not a popular way of transmitting video. If you are planning to stream that video, you should be looking for a established protocol for doing just that.

Base64是一种方便（但效率不高）的二进制数据传输方式。这是低效的，因为传输大小将比您最初传输的大小大 33%。Si 这不是一种流行的视频传输方式。如果您打算流式传输该视频，则应该寻找一种既定的协议来执行此操作。

I would recommend a streaming protocol (there are a lot where you can chose from).

我会推荐一个流媒体协议（有很多你可以选择）。