[PATCH v1 1/9] lavu/pix_fmt: add P012 pixel format
P012 is 12bit planner format which is similar to NV12. It using two bytes to store 12bit valid data and 4bit zero in LSB. This format will be used for hardware decode/encode in VAAPI and QSV. Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- libavutil/pixdesc.c | 24 ++++++++++++++++++++++++ libavutil/pixfmt.h | 5 +++++ libavutil/version.h | 2 +- tests/ref/fate/sws-pixdesc-query | 11 +++++++++++ 4 files changed, 41 insertions(+), 1 deletion(-) diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c index 8274713226..38297e2e83 100644 --- a/libavutil/pixdesc.c +++ b/libavutil/pixdesc.c @@ -2147,6 +2147,30 @@ static const AVPixFmtDescriptor av_pix_fmt_descriptors[AV_PIX_FMT_NB] = { }, .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_BE, }, + [AV_PIX_FMT_P012LE] = { + .name = "p012le", + .nb_components = 3, + .log2_chroma_w = 1, + .log2_chroma_h = 1, + .comp = { + { 0, 2, 0, 4, 12, 1, 11, 1 }, /* Y */ + { 1, 4, 0, 4, 12, 3, 11, 1 }, /* U */ + { 1, 4, 2, 4, 12, 3, 11, 3 }, /* V */ + }, + .flags = AV_PIX_FMT_FLAG_PLANAR, + }, + [AV_PIX_FMT_P012BE] = { + .name = "p012be", + .nb_components = 3, + .log2_chroma_w = 1, + .log2_chroma_h = 1, + .comp = { + { 0, 2, 0, 4, 12, 1, 11, 1 }, /* Y */ + { 1, 4, 0, 4, 12, 3, 11, 1 }, /* U */ + { 1, 4, 2, 4, 12, 3, 11, 3 }, /* V */ + }, + .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_BE, + }, [AV_PIX_FMT_P016LE] = { .name = "p016le", .nb_components = 3, diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h index a46acf3c5e..261e1ea352 100644 --- a/libavutil/pixfmt.h +++ b/libavutil/pixfmt.h @@ -360,6 +360,10 @@ enum AVPixelFormat { AV_PIX_FMT_X2RGB10LE, ///< packed RGB 10:10:10, 30bpp, (msb)2X 10R 10G 10B(lsb), little-endian, X=unused/undefined AV_PIX_FMT_X2RGB10BE, ///< packed RGB 10:10:10, 30bpp, (msb)2X 10R 10G 10B(lsb), big-endian, X=unused/undefined + + AV_PIX_FMT_P012LE, ///< like NV12, with 12bpp per component, little-endian + AV_PIX_FMT_P012BE, ///< like NV12, with 12bpp per component, big-endian + AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you want to link with shared libav* because the number of formats might differ between versions }; @@ -450,6 +454,7 @@ enum AVPixelFormat { #define AV_PIX_FMT_Y210 AV_PIX_FMT_NE(Y210BE, Y210LE) #define AV_PIX_FMT_X2RGB10 AV_PIX_FMT_NE(X2RGB10BE, X2RGB10LE) +#define AV_PIX_FMT_P012 AV_PIX_FMT_NE(P012BE, P012LE) /** * Chromaticity coordinates of the source primaries. diff --git a/libavutil/version.h b/libavutil/version.h index 3ce9b1831e..a63f79feb1 100644 --- a/libavutil/version.h +++ b/libavutil/version.h @@ -79,7 +79,7 @@ */ #define LIBAVUTIL_VERSION_MAJOR 56 -#define LIBAVUTIL_VERSION_MINOR 55 +#define LIBAVUTIL_VERSION_MINOR 56 #define LIBAVUTIL_VERSION_MICRO 100 #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \ diff --git a/tests/ref/fate/sws-pixdesc-query b/tests/ref/fate/sws-pixdesc-query index c3cccfa492..f738a3ad74 100644 --- a/tests/ref/fate/sws-pixdesc-query +++ b/tests/ref/fate/sws-pixdesc-query @@ -57,6 +57,8 @@ isNBPS: nv20le p010be p010le + p012be + p012le x2rgb10be x2rgb10le xyz12be @@ -137,6 +139,7 @@ isBE: grayf32be nv20be p010be + p012be p016be rgb444be rgb48be @@ -188,6 +191,8 @@ isYUV: nv42 p010be p010le + p012be + p012le p016be p016le uyvy422 @@ -282,6 +287,8 @@ isPlanarYUV: nv42 p010be p010le + p012be + p012le p016be p016le yuv410p @@ -365,6 +372,8 @@ isSemiPlanarYUV: nv42 p010be p010le + p012be + p012le p016be p016le @@ -740,6 +749,8 @@ Planar: nv42 p010be p010le + p012be + p012le p016be p016le yuv410p -- 2.17.1
Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- doc/APIchanges | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/APIchanges b/doc/APIchanges index 1d6cc36b8c..75bca69393 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -15,6 +15,9 @@ libavutil: 2017-10-21 API changes, most recent first: +2020-06-12 - 19c969c599 - lavu 56.56.100 - pixdesc.h + Add AV_PIX_FMT_P012. + 2020-06-12 - b09fb030c1 - lavu 56.55.100 - pixdesc.h Add AV_PIX_FMT_X2RGB10. -- 2.17.1
Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- libswscale/input.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++ libswscale/utils.c | 1 + 2 files changed, 53 insertions(+) diff --git a/libswscale/input.c b/libswscale/input.c index 0bd1aa7bc9..b0a7d21e60 100644 --- a/libswscale/input.c +++ b/libswscale/input.c @@ -739,6 +739,46 @@ static void p010BEToUV_c(uint8_t *dstU, uint8_t *dstV, } } +static void p012LEToY_c(uint8_t *dst, const uint8_t *src, const uint8_t *unused1, + const uint8_t *unused2, int width, uint32_t *unused) +{ + int i; + for (i = 0; i < width; i++) { + AV_WN16(dst + i * 2, AV_RL16(src + i * 2) >> 4); + } +} + +static void p012BEToY_c(uint8_t *dst, const uint8_t *src, const uint8_t *unused1, + const uint8_t *unused2, int width, uint32_t *unused) +{ + int i; + for (i = 0; i < width; i++) { + AV_WN16(dst + i * 2, AV_RB16(src + i * 2) >> 4); + } +} + +static void p012LEToUV_c(uint8_t *dstU, uint8_t *dstV, + const uint8_t *unused0, const uint8_t *src1, const uint8_t *src2, + int width, uint32_t *unused) +{ + int i; + for (i = 0; i < width; i++) { + AV_WN16(dstU + i * 2, AV_RL16(src1 + i * 4 + 0) >> 4); + AV_WN16(dstV + i * 2, AV_RL16(src1 + i * 4 + 2) >> 4); + } +} + +static void p012BEToUV_c(uint8_t *dstU, uint8_t *dstV, + const uint8_t *unused0, const uint8_t *src1, const uint8_t *src2, + int width, uint32_t *unused) +{ + int i; + for (i = 0; i < width; i++) { + AV_WN16(dstU + i * 2, AV_RB16(src1 + i * 4 + 0) >> 4); + AV_WN16(dstV + i * 2, AV_RB16(src1 + i * 4 + 2) >> 4); + } +} + static void p016LEToUV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t *unused0, const uint8_t *src1, const uint8_t *src2, int width, uint32_t *unused) @@ -1249,6 +1289,12 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c) case AV_PIX_FMT_P010BE: c->chrToYV12 = p010BEToUV_c; break; + case AV_PIX_FMT_P012LE: + c->chrToYV12 = p012LEToUV_c; + break; + case AV_PIX_FMT_P012BE: + c->chrToYV12 = p012BEToUV_c; + break; case AV_PIX_FMT_P016LE: c->chrToYV12 = p016LEToUV_c; break; @@ -1692,6 +1738,12 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c) case AV_PIX_FMT_P010BE: c->lumToYV12 = p010BEToY_c; break; + case AV_PIX_FMT_P012LE: + c->lumToYV12 = p012LEToY_c; + break; + case AV_PIX_FMT_P012BE: + c->lumToYV12 = p012BEToY_c; + break; case AV_PIX_FMT_GRAYF32LE: #if HAVE_BIGENDIAN c->lumToYV12 = grayf32ToY16_bswap_c; diff --git a/libswscale/utils.c b/libswscale/utils.c index dcd1dbaa76..dd2e3f6a75 100644 --- a/libswscale/utils.c +++ b/libswscale/utils.c @@ -272,6 +272,7 @@ static const FormatEntry format_entries[] = { [AV_PIX_FMT_NV42] = { 1, 1 }, [AV_PIX_FMT_Y210LE] = { 1, 0 }, [AV_PIX_FMT_X2RGB10LE] = { 1, 1 }, + [AV_PIX_FMT_P012LE] = { 1, 0 }, }; int sws_isSupportedInput(enum AVPixelFormat pix_fmt) -- 2.17.1
Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- libavcodec/hevcdec.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c index c9e28f5826..d9c54fbc6a 100644 --- a/libavcodec/hevcdec.c +++ b/libavcodec/hevcdec.c @@ -433,6 +433,10 @@ static enum AVPixelFormat get_format(HEVCContext *s, const HEVCSPS *sps) #endif break; case AV_PIX_FMT_YUV420P12: +#if CONFIG_HEVC_VAAPI_HWACCEL + *fmt++ = AV_PIX_FMT_VAAPI; +#endif + break; case AV_PIX_FMT_YUV444P10: case AV_PIX_FMT_YUV444P12: #if CONFIG_HEVC_NVDEC_HWACCEL -- 2.17.1
The format will be used for VAAPI and QSV HEVC/VP9 12bit decode. Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- libavutil/hwcontext_vaapi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index b31cf95850..b93d8f23e8 100644 --- a/libavutil/hwcontext_vaapi.c +++ b/libavutil/hwcontext_vaapi.c @@ -125,6 +125,9 @@ static const VAAPIFormatDescriptor vaapi_format_map[] = { MAP(Y800, YUV400, GRAY8, 0), #ifdef VA_FOURCC_P010 MAP(P010, YUV420_10BPP, P010, 0), +#endif +#ifdef VA_FOURCC_P012 + MAP(P012, YUV420_12, P012LE, 0), #endif MAP(BGRA, RGB32, BGRA, 0), MAP(BGRX, RGB32, BGR0, 0), -- 2.17.1
Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- libavcodec/vaapi_decode.c | 3 +++ libavcodec/vaapi_hevc.c | 3 +++ 2 files changed, 6 insertions(+) diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c index 5e4f62baad..1188f530c2 100644 --- a/libavcodec/vaapi_decode.c +++ b/libavcodec/vaapi_decode.c @@ -269,6 +269,9 @@ static const struct { #ifdef VA_FOURCC_P010 MAP(P010, P010), #endif +#ifdef VA_FOURCC_P012 + MAP(P012, P012), +#endif #ifdef VA_FOURCC_I010 MAP(I010, YUV420P10), #endif diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c index 9083331c45..4b363e047b 100644 --- a/libavcodec/vaapi_hevc.c +++ b/libavcodec/vaapi_hevc.c @@ -553,6 +553,9 @@ VAProfile ff_vaapi_parse_hevc_rext_profile(AVCodecContext *avctx) else if (!strcmp(profile->name, "Main 4:4:4 10") || !strcmp(profile->name, "Main 4:4:4 10 Intra")) return VAProfileHEVCMain444_10; + else if (!strcmp(profile->name, "Main 12") || + !strcmp(profile->name, "Main 12 Intra")) + return VAProfileHEVCMain12; #else av_log(avctx, AV_LOG_WARNING, "HEVC profile %s is " "not supported with this VA version.\n", profile->name); -- 2.17.1
By using bits per pixel in finding best pix fmt will make the result more accurate. For example, the src fmt is AV_PIX_FMT_YUV420P10LE and dst fmt are AV_PIX_FMT_P012LE and AV_PIX_FMT_P010LE. In this case the two dst fmts have the same scores and padded bits and number of components and P012 will be chosen finally. So add the bits per pixel as one of conditions will return P010 which should be the best choice compare with src fmt. Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- libavutil/pixdesc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c index 38297e2e83..354441e840 100644 --- a/libavutil/pixdesc.c +++ b/libavutil/pixdesc.c @@ -2890,6 +2890,7 @@ enum AVPixelFormat av_find_best_pix_fmt_of_2(enum AVPixelFormat dst_pix_fmt1, en int loss1, loss2, loss_mask; const AVPixFmtDescriptor *desc1 = av_pix_fmt_desc_get(dst_pix_fmt1); const AVPixFmtDescriptor *desc2 = av_pix_fmt_desc_get(dst_pix_fmt2); + const AVPixFmtDescriptor *src = av_pix_fmt_desc_get(src_pix_fmt); int score1, score2; if (!desc1) { @@ -2905,8 +2906,11 @@ enum AVPixelFormat av_find_best_pix_fmt_of_2(enum AVPixelFormat dst_pix_fmt1, en score2 = get_pix_fmt_score(dst_pix_fmt2, src_pix_fmt, &loss2, loss_mask); if (score1 == score2) { - if(av_get_padded_bits_per_pixel(desc2) != av_get_padded_bits_per_pixel(desc1)) { + if (av_get_padded_bits_per_pixel(desc2) != av_get_padded_bits_per_pixel(desc1)) { dst_pix_fmt = av_get_padded_bits_per_pixel(desc2) < av_get_padded_bits_per_pixel(desc1) ? dst_pix_fmt2 : dst_pix_fmt1; + } else if (av_get_bits_per_pixel(desc2) == av_get_bits_per_pixel(src) || + av_get_bits_per_pixel(desc1) == av_get_bits_per_pixel(src)) { + dst_pix_fmt = av_get_bits_per_pixel(desc2) == av_get_bits_per_pixel(src) ? dst_pix_fmt2 : dst_pix_fmt1; } else { dst_pix_fmt = desc2->nb_components < desc1->nb_components ? dst_pix_fmt2 : dst_pix_fmt1; } -- 2.17.1
Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- libavutil/tests/pixfmt_best.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/tests/pixfmt_best.c b/libavutil/tests/pixfmt_best.c index 53f7264207..01387c7c98 100644 --- a/libavutil/tests/pixfmt_best.c +++ b/libavutil/tests/pixfmt_best.c @@ -133,7 +133,7 @@ int main(void) TEST(AV_PIX_FMT_RGB48LE, AV_PIX_FMT_RGB48); // Opaque formats are least unlike each other. - TEST(AV_PIX_FMT_DXVA2_VLD, AV_PIX_FMT_VDPAU); + TEST(AV_PIX_FMT_DXVA2_VLD, AV_PIX_FMT_VAAPI); printf("%d tests passed, %d tests failed.\n", pass, fail); return !!fail; -- 2.17.1
The new test case can cover the issue mentioned in commit 97ba9c1a Signed-off-by: Fei Wang <fei.w.wang@intel.com> --- libavutil/tests/pixfmt_best.c | 18 ++++++++++++++++++ tests/ref/fate/pixfmt_best | 2 +- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/libavutil/tests/pixfmt_best.c b/libavutil/tests/pixfmt_best.c index 01387c7c98..30a41b1fa6 100644 --- a/libavutil/tests/pixfmt_best.c +++ b/libavutil/tests/pixfmt_best.c @@ -66,6 +66,21 @@ int main(void) ++pass; \ } while (0) +#define TEST_SPECIFIC(src, dst1, dst2, expected) do { \ + output = av_find_best_pix_fmt_of_2(dst1, dst2, \ + src, 0, NULL); \ + if (output != expected) { \ + printf("Matching %s with %s and %s: got %s, expected %s\n", \ + av_get_pix_fmt_name(src), \ + av_get_pix_fmt_name(dst1), \ + av_get_pix_fmt_name(dst2), \ + av_get_pix_fmt_name(output), \ + av_get_pix_fmt_name(expected)); \ + ++fail; \ + } else \ + ++pass; \ + } while (0) + // Same formats. for (i = 0; i < FF_ARRAY_ELEMS(pixfmt_list); i++) TEST(pixfmt_list[i], pixfmt_list[i]); @@ -135,6 +150,9 @@ int main(void) // Opaque formats are least unlike each other. TEST(AV_PIX_FMT_DXVA2_VLD, AV_PIX_FMT_VAAPI); + // Specific test list + TEST_SPECIFIC(AV_PIX_FMT_YUV420P10LE, AV_PIX_FMT_P012LE, AV_PIX_FMT_P010LE, AV_PIX_FMT_P010LE); + printf("%d tests passed, %d tests failed.\n", pass, fail); return !!fail; } diff --git a/tests/ref/fate/pixfmt_best b/tests/ref/fate/pixfmt_best index 5f51e2d845..1da1846275 100644 --- a/tests/ref/fate/pixfmt_best +++ b/tests/ref/fate/pixfmt_best @@ -1 +1 @@ -73 tests passed, 0 tests failed. +74 tests passed, 0 tests failed. -- 2.17.1
On Fri, Jun 19, 2020 at 3:53 AM Fei Wang <fei.w.wang@intel.com> wrote:
P012 is 12bit planner format which is similar to NV12. It using two bytes to store 12bit valid data and 4bit zero in LSB. This format will be used for hardware decode/encode in VAAPI and QSV.
P012 is not required, you can just use P016. All these P* formats have the advantage of being aligned to MSB, which means the bitdepth does not matter for their layout. Instead you can use P016 and if you must know, look at a bitdepth value separately. - Hendrik
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Hendrik Leppkes Sent: Friday, June 19, 2020 3:21 PM To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v1 1/9] lavu/pix_fmt: add P012 pixel format
On Fri, Jun 19, 2020 at 3:53 AM Fei Wang <fei.w.wang@intel.com> wrote:
P012 is 12bit planner format which is similar to NV12. It using two bytes to store 12bit valid data and 4bit zero in LSB. This format will be used for hardware decode/encode in VAAPI and QSV.
P012 is not required, you can just use P016. All these P* formats have the advantage of being aligned to MSB, which means the bitdepth does not matter for their layout. Instead you can use P016 and if you must know, look at a bitdepth value separately. If using P016 instead of P012 for 12bit clips, that means for 16bit clips we also need to use P016, which will bring the conflict with current VAAPI logic. It need to resolve same av format map to different RT format and VA format. @Mark Thompson, how about your opinion of this?
The other reason that I used P012 is that P010 also existed in ffempg, but not replaced by P016. Fei
- Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Am Fr., 19. Juni 2020 um 10:27 Uhr schrieb Wang, Fei W <fei.w.wang@intel.com>:
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Hendrik Leppkes Sent: Friday, June 19, 2020 3:21 PM To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v1 1/9] lavu/pix_fmt: add P012 pixel format
On Fri, Jun 19, 2020 at 3:53 AM Fei Wang <fei.w.wang@intel.com> wrote:
P012 is 12bit planner format which is similar to NV12. It using two bytes to store 12bit valid data and 4bit zero in LSB. This format will be used for hardware decode/encode in VAAPI and QSV.
P012 is not required, you can just use P016. All these P* formats have the advantage of being aligned to MSB, which means the bitdepth does not matter for their layout. Instead you can use P016 and if you must know, look at a bitdepth value separately. If using P016 instead of P012 for 12bit clips, that means for 16bit clips we also need to use P016, which will bring the conflict with current VAAPI logic.
Then fix the logic, it is easy to detect how many significant bits the data contains. Carl Eugen
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Carl Eugen Hoyos Sent: Saturday, June 20, 2020 12:59 AM To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v1 1/9] lavu/pix_fmt: add P012 pixel format
Am Fr., 19. Juni 2020 um 10:27 Uhr schrieb Wang, Fei W <fei.w.wang@intel.com>:
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Hendrik Leppkes Sent: Friday, June 19, 2020 3:21 PM To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH v1 1/9] lavu/pix_fmt: add P012 pixel format
On Fri, Jun 19, 2020 at 3:53 AM Fei Wang <fei.w.wang@intel.com> wrote:
P012 is 12bit planner format which is similar to NV12. It using two bytes to store 12bit valid data and 4bit zero in LSB. This format will be used for hardware decode/encode in VAAPI and QSV.
P012 is not required, you can just use P016. All these P* formats have the advantage of being aligned to MSB, which means the bitdepth does not matter for their layout. Instead you can use P016 and if you must know, look at a bitdepth value separately. If using P016 instead of P012 for 12bit clips, that means for 16bit clips we also need to use P016, which will bring the conflict with current
VAAPI logic.
Then fix the logic, it is easy to detect how many significant bits the data contains. Yes, it is not hard to refine the logic, and before the action I'd like to listen From Mark Thompson, the maintainer of VAAPI to reach an agreement.
Kindly Ping @Mark Thompson
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 19/06/2020 08:21, Hendrik Leppkes wrote:
On Fri, Jun 19, 2020 at 3:53 AM Fei Wang <fei.w.wang@intel.com> wrote:
P012 is 12bit planner format which is similar to NV12. It using two bytes to store 12bit valid data and 4bit zero in LSB. This format will be used for hardware decode/encode in VAAPI and QSV.
P012 is not required, you can just use P016. All these P* formats have the advantage of being aligned to MSB, which means the bitdepth does not matter for their layout. Instead you can use P016 and if you must know, look at a bitdepth value separately.
Tracking it separately does not seem fun - it looks to me like it would require adding a new bit depth field to AVFrame. FFmpeg has always used pixfmt as defining both the memory layout and which bits are used in that (so, for example, ARGB and 0RGB are not the same thing), unlike most of the graphics APIs which tend to define those two separately. - Mark
Am So., 28. Juni 2020 um 23:01 Uhr schrieb Mark Thompson <sw@jkqxz.net>:
FFmpeg has always used pixfmt as defining both the memory layout and which bits are used in that (so, for example, ARGB and 0RGB are not the same thing)
But they have the same bitdepth per component... Carl Eugen
Agree with Mark. P012 and P016 have different significant bits, we should use different pixfmts, otherwise an extra field in AVFrame is needed for bit depth. BTW there are the YUV420P variants for 10 / 12 / 14 / 16 bit in FFmpeg, it would be better to follow FFmpeg's style to introduce P012 format instead of reusing P016. Thanks Haihao
Am So., 28. Juni 2020 um 23:01 Uhr schrieb Mark Thompson <sw@jkqxz.net>:
FFmpeg has always used pixfmt as defining both the memory layout and which bits are used in that (so, for example, ARGB and 0RGB are not the same thing)
But they have the same bitdepth per component...
Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Xiang, Haihao Sent: Tuesday, June 30, 2020 15:34 To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v1 1/9] lavu/pix_fmt: add P012 pixel format
Am So., 28. Juni 2020 um 23:01 Uhr schrieb Mark Thompson <sw@jkqxz.net>:
FFmpeg has always used pixfmt as defining both the memory layout and which bits are used in that (so, for example, ARGB and 0RGB are not the same thing)
But they have the same bitdepth per component...
Agree with Mark. P012 and P016 have different significant bits, we should use different pixfmts, otherwise an extra field in AVFrame is needed for bit depth.
BTW there are the YUV420P variants for 10 / 12 / 14 / 16 bit in FFmpeg, it would be better to follow FFmpeg's style to introduce P012 format instead of reusing P016.
Sorry for picking up this old thread. We'd like to add the support for 12bit decoding / encoding in VAAPI and QSV. Is there any other concern if adding P012 in FFmpeg ? Thanks Haihao
Am Fr., 21. Jan. 2022 um 06:56 Uhr schrieb Xiang, Haihao <haihao.xiang-at-intel.com@ffmpeg.org>:
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Xiang, Haihao Sent: Tuesday, June 30, 2020 15:34 To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v1 1/9] lavu/pix_fmt: add P012 pixel format
Am So., 28. Juni 2020 um 23:01 Uhr schrieb Mark Thompson <sw@jkqxz.net>:
FFmpeg has always used pixfmt as defining both the memory layout and which bits are used in that (so, for example, ARGB and 0RGB are not the same thing)
But they have the same bitdepth per component...
Agree with Mark. P012 and P016 have different significant bits, we should use different pixfmts, otherwise an extra field in AVFrame is needed for bit depth.
BTW there are the YUV420P variants for 10 / 12 / 14 / 16 bit in FFmpeg, it would be better to follow FFmpeg's style to introduce P012 format instead of reusing P016.
I was under the impression that YUV420P12 is much more different from YUV420P16 than P012 from P016: Did I misunderstand? (Reading the thread again, I don't think I did)
Sorry for picking up this old thread.
We'd like to add the support for 12bit decoding / encoding in VAAPI and QSV. Is there any other concern if adding P012 in FFmpeg ?
Did you already explain why you cannot use P016 or in which situation it would create a different output? Carl Eugen
On Sun, 2022-01-23 at 01:06 +0100, Carl Eugen Hoyos wrote:
Am Fr., 21. Jan. 2022 um 06:56 Uhr schrieb Xiang, Haihao <haihao.xiang-at-intel.com@ffmpeg.org>:
-----Original Message----- From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Xiang, Haihao Sent: Tuesday, June 30, 2020 15:34 To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v1 1/9] lavu/pix_fmt: add P012 pixel format
Am So., 28. Juni 2020 um 23:01 Uhr schrieb Mark Thompson <sw@jkqxz.net>:
FFmpeg has always used pixfmt as defining both the memory layout and which bits are used in that (so, for example, ARGB and 0RGB are not the same thing)
But they have the same bitdepth per component... Agree with Mark. P012 and P016 have different significant bits, we should use different pixfmts, otherwise an extra field in AVFrame is needed for bit depth.
BTW there are the YUV420P variants for 10 / 12 / 14 / 16 bit in FFmpeg, it would be better to follow FFmpeg's style to introduce P012 format instead of reusing P016.
I was under the impression that YUV420P12 is much more different from YUV420P16 than P012 from P016: Did I misunderstand? (Reading the thread again, I don't think I did)
I understand YUV420P12 is a LSB format, so YUV420P12 can't be taken as YUV420P16. The style here means FFmpeg uses pixfmt for both memory layout and bit depth.
Sorry for picking up this old thread.
We'd like to add the support for 12bit decoding / encoding in VAAPI and QSV. Is there any other concern if adding P012 in FFmpeg ?
Did you already explain why you cannot use P016 or in which situation it would create a different output?
$ ffmpeg -hwaccel vaapi -f rawvideo -pix_fmt p016 -s 1920x1080 -i input.yuv -vf "hwupload,format=vaapi" -c:v hevc_vaapi -f null - If using P016, how will we know the input is 12bit indeed, not 14/16bit if hevc_vaapi may support both 12bit and 14/16bit inputs in the future ? Will we add a new option to ffmpeg to specify the bit depth and a new flag in AVFrame ? Thanks Haihao
Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Am Mi., 26. Jan. 2022 um 09:33 Uhr schrieb Xiang, Haihao <haihao.xiang-at-intel.com@ffmpeg.org>:
Did you already explain why you cannot use P016 or in which situation it would create a different output?
$ ffmpeg -hwaccel vaapi -f rawvideo -pix_fmt p016 -s 1920x1080 -i input.yuv -vf "hwupload,format=vaapi" -c:v hevc_vaapi -f null -
If using P016, how will we know the input is 12bit indeed
Thank you for explaining this, at least I didn't realize this reason earlier! I hope we can find another solution than to add an additional pix_fmt. I believe I had suggested an additional property bit_depth for raw video a long time ago. Carl Eugen
participants (6)
-
Carl Eugen Hoyos -
Fei Wang -
Hendrik Leppkes -
Mark Thompson -
Wang, Fei W
-
Xiang, Haihao