此解决方案华而不实，恕我直言，但是此repo仅仅适用于及其简单的加密比如加个文件头，而那远非真正的"加密",因为随便拿一个notepad就能破解。真正的加密应该是逐字节/比特加密。但是由于nanohttpd的自身机制，当解密播放几十~上百mb的逐字节加密视频（比如逐字节取反）时，会有非常非常大的启动延迟。所以使用nanohttpd搭建解密伺服，仅适用于及其简单加密视频，或者低于二十mb的逐字节加密视频。那样的话，还不直接解密到磁盘在播放呢。

[KnIfER]

The solution is in a way specious,at the risk of sounding implite,but I'm sure that the repo applies only to simple encryption, such as adding a file header, which is far from a real "encryption" because it can be decrypted with a notepad. True encryption should be byte by byte/bit by bit encryption. But because of the nanohttpd's intrinsic mechanism, there will be very, very large startup delays when decrypting dozens of up to hundreds of MB byte-by-byte encrypted video, such as byte-by-byte inverted video(java operator). So using nanohttpd to build decryption servers only applies to simple encrypted video, or per byte encrypted video less than 20MB or so. In that case, directly decryption to disk and playing it will be a better solution,isn't it?
百度翻译真是太棒了！
此解决方案华而不实，恕我直言，但是此repo仅仅适用于及其简单的加密比如加个文件头，而那远非真正的"加密",因为随便拿一个notepad就能破解。真正的加密应该是逐字节/比特加密。但是由于nanohttpd的自身机制，当解密播放几十上百mb的逐字节加密视频（比如逐字节取反）时，会有非常非常大的启动延迟。所以使用nanohttpd搭建解密伺服，仅适用于及其简单加密视频，或者低于二十mb的逐字节加密视频。那样的话，还不直接解密到磁盘在播放呢。