有没有大人能解个惑。这个链接：ShanaEncoder官方版下载丨最新版下载丨绿色版下载丨APP下载-123云盘
里面是某软件的压缩包资源，200多兆压缩成了40多兆，可我解压之后自己压缩，用最大压缩比的7z和bandizip都试过了极限压缩最低也只能到60多兆。。
另一个重点：我极限压缩成60多兆时，压缩和解压也都慢，但是这个40多兆的压缩比这么高，但是解压非常快，几乎是秒开，这是什么黑科技？有没有懂哥科普一下，或者来研究研究！
1 个赞
好像和数据的结构有关，据说如果文件的重复性比较高，压缩比就很容易提得比较高。
举个例子，比如有一批数据，是20个字母 “A”，就像这样：
AAAAAAAAAAAAAAAAAAAA
这就很好压缩了，可以直接压缩成很少的几个字符：
A[20]
但如果这批数据是20个随机字母，那就很难压缩了：
ABSHEJSHDKWOEMWPSKDN
这个道理我懂，但这是同一批文件，，，无论我如何调整极限压缩的参数，都达不到40+MB的大小，最低只能到65MB
https://www.bilibili.com/opus/992135491170074663
按这个试了下，出来的包也是39.1M
那应该是压缩算法的问题，您可以参考楼上给出的链接重新选择一下压缩算法。
压缩前看看对话框里的算法
2个工具，会尝试各种参数组合来使压缩包更小…
6 个赞
貌似是开发大佬专家自己整的一套看家本领算法
就像是压缩视频一样，
因为他用BCJ2二进制文件处理，再LZMA2最大化压缩，
BCJ2方式对x86平台下exe文件做了特别优化
优化了x86/x64程序中的跳转指令（Jumps） 、函数调用（Calls） 和分支指令（Branches）
BCJ2先预处理可执行文件，提高可执行文件中重复（可以被压缩）的内容比例
这算是一个对X86程序的针对性优化
实际测试了一下，
原始压缩包31.15MB（41,053,036 字节）
下图参数压缩后为31.15MB（41,050,213 字节）
甚至比原始压缩包还小了一点点
13 个赞
试了下，主要是“底部的参数框填入f=BCJ2”这条起到的作用，具体缘由应该是
说到的这样，破案了，感谢各位大佬 
7-Zip 24.9.0测试，即使不加这个参数，对于可执行文件，默认也会启用BCJ2算法。并且这个算法是根据“文件扩展名”而非“文件数据头”启用的。例如，将1.exe压缩会启用BCJ2，而将其改名为1.f再压缩则不会启用该算法。
压缩效果差这么大，会不会是 固实模式（先合并成一个大文件，类似tar） 的原因？
ffmpeg的压缩包也是这样很神奇地进行了超级压缩，3个130M多的程序和一堆什么docs之类的，硬生生压缩到50m……（
这3个程序里面重复的数据不少，或者说绝大部分体积都是共用的库
你下个带dll的shared版本就会很明显，3个exe体积小，几个dll体积是主要的。我个人也建议用这个版本，解压后也省体积
关于这个发布：
有3种ffmpeg版本，最新的master，还有6.1和7.1版本。
根据开源协议，分为gpl和lgpl版本，没什么特别要求的选gpl，库更全。
另外就是分纯静态(末尾不带shared)和共享dll版(末尾带shared)
系统：普通64位用win64，arm64的用winarm64
2 个赞
我也用这个。理论上编译mpv也能把共享库独立出来，但没找到。
有的，但体积也没小多少…
不过我觉得mpv动态链接ffmpeg可能没想象那么好。如果整个系统都共享一个ffmpeg，就会像linux那样，更新一个软件，所有相关的都要更新。更新mpv时要注意构建是链接到哪个版本的ffmpeg…
多谢。试试对我来说，ffmpeg是需要但不常用的软件。能减少点空间和带宽终究是件好事。
是，新版选最大压缩的话，会自动启用先BCJ2，然后ARM，最后再LZMA2压缩
我用最新版7-ZIP（24.09）再次测试了一下帖子中提到的这个压缩包，不主动填入BCJ2参数选择极限压缩确实比之前老版本7Z极限压缩（75Mb）的更小一些（60+Mb），但还是达不到主动填入BCJ2参数之后的（39.1Mb）