| Message ID | 20220727152447.30944-1-george@nsup.org |
|---|---|
| State | New |
| Headers | show |
| Series | [FFmpeg-devel] lavu/pixfmt: summarize yuv naming conventions | expand |
| Context | Check | Description |
|---|---|---|
| yinshiyou/make_loongarch64 | success | Make finished |
| yinshiyou/make_fate_loongarch64 | success | Make fate finished |
| andriy/make_x86 | success | Make finished |
| andriy/make_fate_x86 | success | Make fate finished |
On Wed, Jul 27, 2022 at 5:25 PM Nicolas George <george@nsup.org> wrote: > > Signed-off-by: Nicolas George <george@nsup.org> > --- > libavutil/pixfmt.h | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > > Note: we have log2_chroma_h = 2 for yuv410p, meaning each chroma pixel > is 4×4 luma pixels, but everywhere I look on the web, ilcuding: > https://en.wikipedia.org/wiki/Chroma_subsampling > I find that it is supposed to be 4×2, and we should set log2_chroma_h = 1. > Who is right? Following the actual naming convention, you would arrive at a 4x2 grid, however even the Wikipedia article linked above is inconsistent with that. In the first section describing how the naming convention works, it lists an exception that 4:1:0 is supposedly referencing a 4x4 grid, however further down where 4:1:0 is being detailed, this is no longer the case. Many other resources just seem to copy this second Wikipedia description. We have a variety of decoders that use this format as it is defined right now, presumably successfully. Of course that could just mean this format exists, and is just named wrong, on the other hand, did any decoder ever require the one pixel per 4x4 grid format, giving any technical baking to the other interpretation? - Hendrik
Hendrik Leppkes (12022-07-27): > Following the actual naming convention, you would arrive at a 4x2 > grid, however even the Wikipedia article linked above is inconsistent > with that. In the first section describing how the naming convention > works, it lists an exception that 4:1:0 is supposedly referencing a > 4x4 grid, however further down where 4:1:0 is being detailed, this is > no longer the case. > Many other resources just seem to copy this second Wikipedia description. > > We have a variety of decoders that use this format as it is defined > right now, presumably successfully. Of course that could just mean > this format exists, and is just named wrong, on the other hand, did > any decoder ever require the one pixel per 4x4 grid format, giving any > technical baking to the other interpretation? Thanks for the clarification. Let us leave it as it is. Regards,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h index 2d3927cc3f..3d0f92ed4d 100644 --- a/libavutil/pixfmt.h +++ b/libavutil/pixfmt.h @@ -60,6 +60,23 @@ * For all the 8 bits per pixel formats, an RGB32 palette is in data[1] like * for pal8. This palette is filled in automatically by the function * allocating the picture. + * + * @par + * Summary of the naming conventions for YUV formats: + * 444 422 440 420 411 410 + * ╋━╋━╋━╋━╋ ╋━┿━╋━┿━╋ ╋━╋━╋━╋━╋ ╋━┿━╋━┿━╋ ╋━┿━┿━┿━╋ ╋━┿━┿━┿━╋ + * ╋━╋━╋━╋━╋ ╋━┿━╋━┿━╋ ╂─╂─╂─╂─╂ ╂─┼─╂─┼─╂ ╋━┿━┿━┿━╋ ╂─┼─┼─┼─╂ + * ╋━╋━╋━╋━╋ ╋━┿━╋━┿━╋ ╋━╋━╋━╋━╋ ╋━┿━╋━┿━╋ ╋━┿━┿━┿━╋ ╂─┼─┼─┼─╂ + * ╋━╋━╋━╋━╋ ╋━┿━╋━┿━╋ ╂─╂─╂─╂─╂ ╂─┼─╂─┼─╂ ╋━┿━┿━┿━╋ ╂─┼─┼─┼─╂ + * ╋━╋━╋━╋━╋ ╋━┿━╋━┿━╋ ╋━╋━╋━╋━╋ ╋━┿━╋━┿━╋ ╋━┿━┿━┿━╋ ╋━┿━┿━┿━╋ + * where + * ┼─┼ = luma pixel ╋━╋ = chroma pixel + * ┼─┼ ╋━╋ + * + * yuv4ab → + * log2_chroma_w = log₂(4/a) + * log2_chroma_h = b == a ? 0 : b == 0 ? log2_chroma_w : unused + * i.e. a = horizontally, number of luma pixels for four chroma pixels */ enum AVPixelFormat { AV_PIX_FMT_NONE = -1,
Signed-off-by: Nicolas George <george@nsup.org> --- libavutil/pixfmt.h | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) Note: we have log2_chroma_h = 2 for yuv410p, meaning each chroma pixel is 4×4 luma pixels, but everywhere I look on the web, ilcuding: https://en.wikipedia.org/wiki/Chroma_subsampling I find that it is supposed to be 4×2, and we should set log2_chroma_h = 1. Who is right? Regards,