我已阅读 BT.709 spec很多次，只是不清楚的是编码的 H.264 比特流是否应该将任何 Gamma 曲线应用于编码数据？请注意在 BT.709 规范中特别提到了类似 Gamma 的公式。 Apple 提供了从 CoreVideo 提供的缓冲区读取 YUV 数据的 OpenGL 或 Metal 着色器示例，它们不进行任何类型的 gamma 调整。正在读取和处理 YUV 值，就好像它们是简单的线性值一样。我还检查了 ffmpeg 的源代码，发现在 BT.709 缩放步骤之后没有应用 Gamma 调整。我然后created a test video只有两个线性灰度颜色 5 和 26 对应于 2% 和 10% 级别。当使用 ffmpeg 和 iMovie 转换为 H.264 时，输出 BT.709 值为 (YCbCr) (20 128 128) 和 (38 128 128)，这些值与 BT.709 转换矩阵的输出完全匹配，没有任何 Gamma 调整。

可以在 Quicktime Gamma Bug 找到有关该主题的大量背景资料。 .似乎 Quicktime 和 Adob​​e 编码器的一些历史问题不正确地进行了不同的 gamma 调整，结果导致视频流在不同的播放器上看起来很糟糕。这真的很令人困惑，因为如果你比较 sRGB ，它清楚地指示了如何应用 Gamma 编码然后对其进行解码以在 sRGB 和线性之间进行转换。如果在创建 h.264 数据流时的矩阵步骤之后没有应用 Gamma 调整，为什么 BT.709 会详细介绍相同类型的 Gamma 调整曲线？ h.264 流中的所有颜色步骤是否都意味着编码为直线( Gamma 1.0)值？

如果特定的示例输入会让事情变得更清楚，我附上了 3 个颜色条图像，不同颜色的确切值可以使用这些图像文件显示在图像编辑器中。

第一个图像在 sRGB 颜色空间中，并被标记为 sRGB。



第二张图像已转换为线性 RGB 颜色空间，并使用线性 RGB 配置文件进行标记。



这第三张图像已通过来自 elles_icc_profiles 的 Rec709-elle-V4-rec709.icc 转换为 REC.709 配置文件级别.这似乎是模拟 BT.709 中描述的“相机” Gamma 所需要做的事情。



请注意右下角 (0x555555) 的 sRGB 值如何变为线性 RGB (0x171717) 以及 BT.709 Gamma 编码值如何变为 (0x464646)。不清楚的是我是否应该将线性 RGB 值传递给 ffmpeg，或者我是否应该传递一个已经 BT.709 Gamma 编码的值，然后需要在客户端中对其进行解码，然后再进行线性转换矩阵步骤以返回 RGB .

更新:

根据反馈，我更新了基于 C 的实现和 Metal 着色器，并作为 iOS 示例项目上传到 github MetalBT709Decoder .

编码一个归一化的线性 RGB 值是这样实现的:

static inline
int BT709_convertLinearRGBToYCbCr(
                            float Rn,
                            float Gn,
                            float Bn,
                            int *YPtr,
                            int *CbPtr,
                            int *CrPtr,
                            int applyGammaMap)
{
  // Gamma adjustment to non-linear value

  if (applyGammaMap) {
    Rn = BT709_linearNormToNonLinear(Rn);
    Gn = BT709_linearNormToNonLinear(Gn);
    Bn = BT709_linearNormToNonLinear(Bn);
  }

  // https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf

  float Ey = (Kr * Rn) + (Kg * Gn) + (Kb * Bn);
  float Eb = (Bn - Ey) / Eb_minus_Ey_Range;
  float Er = (Rn - Ey) / Er_minus_Ey_Range;

  // Quant Y to range [16, 235] (inclusive 219 values)
  // Quant Eb, Er to range [16, 240] (inclusive 224 values, centered at 128)

  float AdjEy = (Ey * (YMax-YMin)) + 16;
  float AdjEb = (Eb * (UVMax-UVMin)) + 128;
  float AdjEr = (Er * (UVMax-UVMin)) + 128;

  *YPtr = (int) round(AdjEy);
  *CbPtr = (int) round(AdjEb);
  *CrPtr = (int) round(AdjEr);

  return 0;
}

static inline
int BT709_convertYCbCrToLinearRGB(
                             int Y,
                             int Cb,
                             int Cr,
                             float *RPtr,
                             float *GPtr,
                             float *BPtr,
                             int applyGammaMap)
{
  // https://en.wikipedia.org/wiki/YCbCr#ITU-R_BT.709_conversion
  // http://www.niwa.nu/2013/05/understanding-yuv-values/

  // Normalize Y to range [0 255]
  //
  // Note that the matrix multiply will adjust
  // this byte normalized range to account for
  // the limited range [16 235]

  float Yn = (Y - 16) * (1.0f / 255.0f);

  // Normalize Cb and CR with zero at 128 and range [0 255]
  // Note that matrix will adjust to limited range [16 240]

  float Cbn = (Cb - 128) * (1.0f / 255.0f);
  float Crn = (Cr - 128) * (1.0f / 255.0f);

  const float YScale = 255.0f / (YMax-YMin);
  const float UVScale = 255.0f / (UVMax-UVMin);

  const
  float BT709Mat[] = {
    YScale,   0.000f,  (UVScale * Er_minus_Ey_Range),
    YScale, (-1.0f * UVScale * Eb_minus_Ey_Range * Kb_over_Kg),  (-1.0f * UVScale * Er_minus_Ey_Range * Kr_over_Kg),
    YScale, (UVScale * Eb_minus_Ey_Range),  0.000f,
  };

  // Matrix multiply operation
  //
  // rgb = BT709Mat * YCbCr

  // Convert input Y, Cb, Cr to normalized float values

  float Rn = (Yn * BT709Mat[0]) + (Cbn * BT709Mat[1]) + (Crn * BT709Mat[2]);
  float Gn = (Yn * BT709Mat[3]) + (Cbn * BT709Mat[4]) + (Crn * BT709Mat[5]);
  float Bn = (Yn * BT709Mat[6]) + (Cbn * BT709Mat[7]) + (Crn * BT709Mat[8]);

  // Saturate normalzied linear (R G B) to range [0.0, 1.0]

  Rn = saturatef(Rn);
  Gn = saturatef(Gn);
  Bn = saturatef(Bn);

  // Gamma adjustment for RGB components after matrix transform

  if (applyGammaMap) {
    Rn = BT709_nonLinearNormToLinear(Rn);
    Gn = BT709_nonLinearNormToLinear(Gn);
    Bn = BT709_nonLinearNormToLinear(Bn);
  }

  *RPtr = Rn;
  *GPtr = Gn;
  *BPtr = Bn;

  return 0;
}

#define APPLE_GAMMA_196 (1.960938f)

static inline
float Apple196_nonLinearNormToLinear(float normV) {
  const float xIntercept = 0.05583828f;

  if (normV < xIntercept) {
    normV *= (1.0f / 16.0f);
  } else {
    const float gamma = APPLE_GAMMA_196;
    normV = pow(normV, gamma);
  }

  return normV;
}

static inline
float Apple196_linearNormToNonLinear(float normV) {
  const float yIntercept = 0.00349f;

  if (normV < yIntercept) {
    normV *= 16.0f;
  } else {
    const float gamma = 1.0f / APPLE_GAMMA_196;
    normV = pow(normV, gamma);
  }

  return normV;
}

最佳答案

您最初的问题:带有 BT.709 矩阵的 H.264 编码视频是否包含任何 Gamma 调整？

编码的视频仅包含 Gamma 调整 - 如果您输入编码器 Gamma 调整值。

H.264 编码器不关心传输特性。
所以如果你压缩线性然后解压缩 - 你会得到线性。
所以如果你用 Gamma 压缩然后解压缩 - 你会得到 Gamma 。

或者，如果您的位是用 Rec 编码的。 709 传递函数 - 编码器不会改变 Gamma 。

但是您可以将 H.264 流中的传输特性指定为元数据。 (ITU-T H.264 (04/2017) E.1.1 VUI 参数语法建议书)。因此，编码流携带了色彩空间信息，但不用于编码或解码。

我会假设 8 位视频总是包含一个非线性传递函数。否则你会相当不明智地使用 8 位。

如果您转换为线性来做效果和合成 - 我建议增加位深度或线性化为浮点数。

颜色空间由原色、传递函数和矩阵系数组成。
Gamma 调整在传递函数中编码(而不是在矩阵中)。

关于ios - 带有 BT.709 矩阵的 H.264 编码视频是否包含任何 Gamma 调整？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53911662/