diff options
author | Hans Verkuil <hverkuil@xs4all.nl> | 2017-03-01 12:31:20 -0300 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@s-opensource.com> | 2017-03-22 10:13:26 -0300 |
commit | 79e92dc0ecc64dd221383960a8bc3399c6723d03 (patch) | |
tree | 7856e96485bc1124bd7c3c3a515d908a1ae78cee /kernel | |
parent | 27430d19a91615245babaa9b216d0807636903a0 (diff) | |
download | linux-stable-79e92dc0ecc64dd221383960a8bc3399c6723d03.tar.gz linux-stable-79e92dc0ecc64dd221383960a8bc3399c6723d03.tar.bz2 linux-stable-79e92dc0ecc64dd221383960a8bc3399c6723d03.zip |
[media] videodev2.h: map xvYCC601/709 to limited range quantization
The xvYCC601/709 encodings were mapped by default to full range quantization.
This is actually wrong since these encodings use limited range quantization,
but accept values outside of the limited range.
This makes sense since for values within the limited range it behaves exactly
the same as BT.601 or Rec. 709. The only difference is that with the xvYCC
encodings the values outside of the limited range also produce value colors.
Talking to people who know a lot more about this than I do made me realize
that mapping xvYCC to full range quantization was wrong, so this patch corrects
this and also improves the documentation.
These formats are very rare, and since the formula for decoding these Y'CbCr
encodings is actually fixed and independent of the quantization field value
it is safe to make this change.
The main advantage is that keeps the V4L2 specification in sync with the
corresponding colorspace, HDMI and CEA861 standards when it comes to these
xvYCC formats.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions