ffmpeg - 为什么 LZW 压缩中压缩缓冲区需要大于输入缓冲区?

标签 ffmpeg compression libavcodec libav lzw

我目前正在致力于从 FFmpeg 源代码到我的项目实现 LZW 压缩和解压缩方法。我偶然发现输出缓冲区(将存储压缩数据的位置)的大小需要大于我们要压缩的输入缓冲区的大小。这不是和压缩本身矛盾吗?

下一部分代码位于 ff_lzw_encode()函数是 lzwenc.c 的一部分源文件。

if (insize * 3 > (s->bufsize - s->output_bytes) * 2)
{
    printf("Size of output buffer is too small!\n");
    return -1;
}

对于我的特定示例,我尝试在将原始视频帧发送到本地之前对其进行压缩。但是,如果我为大小为 (insize * 3)/2 的缓冲区分配内存(将存储压缩数据),那么使用 send( ) 功能而不是发送大小为 insize 的原始缓冲区?

最佳答案

您无法保证“压缩”形式的大小小于甚至等于输入的大小。考虑纯随机数据的最坏情况,无法以任何方式压缩,最好的情况是,将被压缩到 100% 原始大小;除此之外,还需要添加一些压缩元数据或转义序列,从而导致例如100% + 5 字节。

事实上,“压缩”不可压缩数据“仅”100% 其原始大小通常不会自动发生。如果算法只是尝试正常压缩输入,结果甚至可能明显大于输入。智能压缩工具会检测到这种情况,然后回退以发送未压缩的数据 block ,然后添加一些元数据以至少指示该 block 未压缩。

您分配的缓冲区必须足够大,以包含最坏情况下的“压缩”字节数,因此需要一些“净空”。

wouldn't that take more time to send using send() function than sending raw buffer

是的,会的。这就是为什么您不发送整个(分配的)缓冲区,而只发送该缓冲区中压缩函数指示已使用的字节数。

关于ffmpeg - 为什么 LZW 压缩中压缩缓冲区需要大于输入缓冲区?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36568587/

相关文章:

linux - 一行获取进程的PID

android - GC 和 onTouch 在通过 ndk 使用 ffmpeg 的应用程序中导致致命信号 11 (SIGSEGV) 错误

ffmpeg - 使用 av_interleaved_write_frame 而不是 avio_write 时为 "moov atom not found"

ffmpeg - 显示 UDP(RGB) 输入到 ffmpeg 或 vlc

c - libav:用 RGB24 样本数据填充 AVFrame?

c# - 无法找到中央目录记录的 System.IO.Compression 结尾

c++ - 以随机顺序接收行时压缩位矩阵

java - 如何在数据结构中压缩多个字符串?

ffmpeg - 存储传入流时如何真正选择正确的格式?