@GeruzoniAnsasu （偷偷提醒一下，帖子的分类）

首先，如果是存数据库，为什么要特意限制 varchar 的长度？
255 字节内的存储成本都是一样的，直接设 varchar(255) ascii 不就行了？

然后 IP 地址存数据库，当然是 VARBINARY(16)咯。
官网找 IPv6 就有全套说明：
https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_inet6-aton

@baoyexi 不是所有的解码器都能适应新的 SPS 的。丢掉 RASL 也不是各大解码器都能做好的。
就连以前最简单的两个分开编码的 h.264 流合在一起出 mp4 都有解码器会炸。

要不先找公证人员做一下取证？既然源代码里有你的网站信息。

用 nginx 自带的字符串替换功能？

@zhangsimon #18
世界上绝大多数的类似功能的产品都是 ffmpeg 套个壳。（少部分是独立编解码器，但是功能肯定少得多。）

至于无转码合并，是可以的，但是要求非常高，要求关键的编码参数必须一致，否则播放的时候会让解码器崩溃。
举个例子，如果你压的是 H.264 ，参考帧开的是 4，而原片开的是 6，那么合并以后如果 SPS/PPS 里说这片只参考了 4 帧，解码器按照 4 帧分配了内部存储结构空间，播到参考帧 6 的地方就会因为 buffer overrun 或者 missing frame 而炸掉。

H.264 的关键参数少说十几个，H.265 的关键参数更多，任何一个参数不匹配都会炸掉解码器。

所以你说，无转码合并难吗？

再来说点更难的。比如电视广播常用的 Open GOP，每一段 GOP 里的帧都有或多或少参考之前一个 GOP 的内容。也就是说，整个视频流可能从凌晨电视台开机开始，到晚上停机休息为止，这十几个小时的视频都没有办法完美切割或者合并。
从开机的第一个 IDR 开始，后面的所有内容就像这样：I B P B P I B P B P 。如果是 Close GOP，那么第 1 帧和第 6 帧都是 IDR 帧，从 GOP 边界切开就能完美分割。如果是 Open GOP，那么这两帧都是 i 帧，意味着第 2 帧和第 7 帧都可以跨 GOP 参考，也就是说第 7 帧上的画面可以从第 5 帧甚至第 3 帧取来做参考。如果你把第一个 GOP 切掉，那么第 7 帧直接就成了无法播放的坏帧了。所以像日本的电视台节目，切开的位置头几帧是肯定要坏掉的。
如果是 H.265 的 4K 节目的话，也有类似的 IDR/CRA/RASL/RADL/TRAIL 帧的区别。
这些基础知识就够咱们研究好久了……

这些东西不是你希望他支持他就能做出来的。有些功能，确实不太现实。

是有可能算的。
对于非自由开源软件，在 GitHub 网站内可以自由复制和分叉，但是搬到其他网站属于侵权。
对于自由开源软件，因为本来就允许使用源代码，所以 push 到其他网站也是允许的。

普通用户都不会配足内存的。
一般需要 16G 内存的人买 8G 就足够了，剩下的交给 SSD 分页文件处理。
余量大点的话 12G-16G 都行。
只有非常少量的用户才会配充足的内存。

我做开发的，没开什么软件，平时日常内存使用量就有 30-35G，配了 32G 内存，物理内存占用 50%左右。

@XIVN1987 我用 G++尝试编译了，C++11/14/17/2x 都能过。

你可以把比较完整的源码贴到 gist，连带你编译的命令一起贴出来看看。

没什么掉价吧。

int main() { std::cout << __cplusplus << std::endl; }

GCC 5.4 = 199711 = C++98

可以看这里 https://gist.github.com/ax3l/53db9fa8a4f4c21ecc5c4100c0d93c94

建议还是不要用 22 年前的标准来跑了。

@datocp 这还是不太一样的。用百度，（ p2p 上线以前）流量至少是百度自己的服务器给你传的。吸血雷是要靠吸别人的血下载的，当然是不太一样了。等百度上线 p2p 计划，也开始从用户手里吸血以后，你用起来就不怕到 99.9%因为一块数据损坏而下不完了。

顺便你想想 Cancel 是怎么拼的（

听说你重新发明了 rclone ？

我现在除了要写汇编的地方用 C++和汇编以外，已经只写 Ruby 了。

经历一下社会的毒打，然后可能就有动力读书了。

就像你不想工作的时候，看看银行的存款，马上就埋头苦干去了。

这不是 JSON 原文，这是把 JSON 又做了一边转义的结果。

比如
var a = "{\"身份\":\"学生\",\"姓名\":\"张三\"}"

a 的内容是什么？
是 {"身份":"学生","姓名":"张三"}

上面 var a 后面的是为了把 JSON 表示成字符串而做的一层额外转义。变量内部是没有斜线的。

所以后台要么给
"{\"身份\":\"学生\",\"姓名\":\"张三\"}"
也就是两次序列化，

要么给
{"身份":"学生","姓名":"张三"}
也就是一次序列化。