RTP/MJPEG流的默认量化表是什么?



我在解码ip-camera的RTP/MJPEG流时遇到了一个问题。

如rfc2435所述,量化表(对于Q值1 <= Q <= 99)应该从这些默认表中计算:

/*
* Table K.1 from JPEG spec.
*/
static const int jpeg_luma_quantizer[64] = {
    16, 11, 10, 16, 24, 40, 51, 61,
    12, 12, 14, 19, 26, 58, 60, 55,
    14, 13, 16, 24, 40, 57, 69, 56,
    14, 17, 22, 29, 51, 87, 80, 62,
    18, 22, 37, 56, 68, 109, 103, 77,
    24, 35, 55, 64, 81, 104, 113, 92,
    49, 64, 78, 87, 103, 121, 120, 101,
    72, 92, 95, 98, 112, 100, 103, 99
};
/*
 * Table K.2 from JPEG spec.
 */
static const int jpeg_chroma_quantizer[64] = {
    17, 18, 24, 47, 99, 99, 99, 99,
    18, 21, 26, 66, 99, 99, 99, 99,
    24, 26, 56, 99, 99, 99, 99, 99,
    47, 66, 99, 99, 99, 99, 99, 99,
    99, 99, 99, 99, 99, 99, 99, 99,
    99, 99, 99, 99, 99, 99, 99, 99,
    99, 99, 99, 99, 99, 99, 99, 99,
    99, 99, 99, 99, 99, 99, 99, 99
};

该算法导致图像质量差(vlc显示更好)。我已经查看了ffmpeg源,并发现了类似的算法,但使用不同的表:

static const uint8_t default_quantizers[128] = {
    /* luma table */
    16,  11,  12,  14,  12,  10,  16,  14,
    13,  14,  18,  17,  16,  19,  24,  40,
    26,  24,  22,  22,  24,  49,  35,  37,
    29,  40,  58,  51,  61,  60,  57,  51,
    56,  55,  64,  72,  92,  78,  64,  68,
    87,  69,  55,  56,  80,  109, 81,  87,
    95,  98,  103, 104, 103, 62,  77,  113,
    121, 112, 100, 120, 92,  101, 103, 99,
    /* chroma table */
    17,  18,  18,  24,  21,  24,  47,  26,
    26,  47,  99,  66,  56,  66,  99,  99,
    99,  99,  99,  99,  99,  99,  99,  99,
    99,  99,  99,  99,  99,  99,  99,  99,
    99,  99,  99,  99,  99,  99,  99,  99,
    99,  99,  99,  99,  99,  99,  99,  99,
    99,  99,  99,  99,  99,  99,  99,  99,
    99,  99,  99,  99,  99,  99,  99,  99
};

我已经将表更改为ffmpeg表,现在图片看起来很完美。那么,为什么这些表与rfc2435不同呢?我错过了什么?

不同的表适合不同的内容。随着时间的推移,也会发现更好的表格。找到最好的表格实际上是使用人类对质量的判断进行试验和错误,然后根据您希望优化的内容类型进行权衡。Ffmpeg也可以生成更大的文件。在最初编写jpeg规范时,较大的文件可能不被接受。

默认值是预先计算的,但您也可以包括自己的Q=100,参见我的实现@ https://net7mma.codeplex.com/SourceControl/latest#Rtp/RFC2435Frame.cs

相关内容

  • 没有找到相关文章

最新更新