2

我在想一个有效的解决方案时遇到了一些麻烦。我预见到了一些问题，第一个是...

OOM 预防

如果我想要过去的 30 秒甚至 5 分钟，这是可行的，但如果我想要过去的 30 分钟或整小时，或者一切呢？保留字节缓冲区意味着将其存储在 RAM 中。存储超过 100 兆字节听起来像是虚拟内存自杀。

好吧，如果我们将之前录制的媒体的 Y 时间量（比如 30 秒）存储到磁盘中的某个 tmp 文件中，那该怎么办。这可能会起作用，我可以使用像 mp4 解析器这样的库在完成后将它们全部连接起来。然而...

如果我们有 30 分钟的价值，那就是大约 60 个 30 秒的剪辑。这似乎是一种烧录 SD 卡的好方法，即使这不是问题，我也无法想象将一百多个文件连接成一个文件所需的时间。

根据我一直在研究的内容，我正在考虑使用本地套接字来做类似的事情......

MediaRecorder -> setOutputFile(LocalSocket.getFD())

然后在本地套接字中......

LocalSocket -> FileOutputStream -> 写入（数据，位置，bufsiz） -> 刷新（）

后台线程处理写入和跟踪位置以及缓冲区的位置。

这纯粹是伪代码，我还不足以测试它，我是否朝着正确的方向前进？从我的想法来看，这只保留一个被覆盖的文件。由于它每 Y 秒只被写入一次，因此它最大限度地减少了 IO 开销，并最大限度地减少了它占用的 RAM 量。

视频长度到缓冲区大小

我将如何从请求的视频大小中获取缓冲区的大小。这很奇怪，因为我看到一些长视频很小，但短视频很大。所以我不知道如何准确地确定这一点。如果我知道从 Media Recorder 设置的视频长度、编码等，任何人都知道如何预测这一点？

例子

有谁知道这方面的任何例子？我不认为这个想法是完全原创的，但我没有看到很多这样的想法，如果是这样，它就是闭源的。一个例子有很长的路要走。

提前致谢

4

1 回答 1

3

Grafika中的“连续捕获”活动使用 MediaCodec 而不是 MediaRecorder 来执行此操作。它将最后 N 秒的视频保存在内存中的循环缓冲区中，并在用户请求时将其写入磁盘。

CircularEncoder 构造函数根据目标比特率估计内存需求。以合理的速率（比如 4Mbps），你需要 1.8GB 来存储一个小时的视频，所以这不适合当前设备的 RAM。五分钟是 150MB，这是推动礼貌的界限。假脱机到磁盘上的文件可能是必要的。

通过套接字传递数据不会给您带来任何您无法从适当的 java.util.concurrent 数据结构中获得的东西。您只是在数据副本中涉及操作系统。

一种方法是创建一个内存映射文件，并以与 CircularEncoder 处理其循环缓冲区相同的方式处理它。在 Grafika 中，帧数据进入单个大字节缓冲区，元数据（告诉你每个数据包的开始和结束位置）位于并行数组中。您可以将帧数据存储在磁盘上，并将元数据保存在内存中。内存映射适用于五分钟的情况，但通常不适用于整小时的情况，因为获得一个很大的连续虚拟地址范围可能会出现问题。

如果没有内存映射 I/O，方法本质上是相同的，但是您必须使用文件 I/O 调用来查找/读取/写入。同样，将帧元数据保存在内存中。

如果磁盘 I/O 停止，则可能需要额外的缓冲阶段。通过 MediaMuxer 写入视频数据时，我看到了周期性的一秒停顿，这比 MediaCodec 缓冲更多，导致丢帧。你可以推迟解决这个问题，直到你确定你确实有问题。

您需要考虑一些额外的细节，例如在开始时丢帧以确保您的视频在同步帧上开始，但您可以看到 Grafika 如何解决这些问题。

于 2015-11-23T19:14:10.010 回答