On 20.10.2018 23:52, Philip Langdale wrote:
On Sat, 20 Oct 2018 22:58:34 +0200 Timo Rothenpieler <t...@rothenpieler.org> wrote:+ // It it semantically incorrect to use AX_PIX_FMT_YUV444P16for either the 10 + // or 12 bit case, but ffmpeg and nvidia disagree on which end the padding + // bits go at. P16 is unambiguous and matches.This comment seems redundant, since AX_PIX_FMT_YUV444P16 isn't even used.Yeah, that's outdated from the original version with no pix fmts. I'll remove it.diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c index 3b1d53e799..43337f14f0 100644 --- a/libavutil/hwcontext_cuda.c +++ b/libavutil/hwcontext_cuda.c @@ -38,6 +38,8 @@ static const enum AVPixelFormat supported_formats[] = { AV_PIX_FMT_YUV444P, AV_PIX_FMT_P010, AV_PIX_FMT_P016, + AV_PIX_FMT_YUV444P10_MSB, + AV_PIX_FMT_YUV444P12_MSB,You are adding these to supported formats, but are not actually adding support, so cuda_frames_init and cuda_get_buffer will both run into the BUG case. Should be super easy, as they're identical to 444P16.This actually works fine. cuda_frames_init and cuda_get_buffer both use generic mechanisms that introspect the pix desc information.
Right, I had the 3.4 branch checked out when checking that...
AV_PIX_FMT_YUV444P16,Technically, this can go now. But I guess removing it is an API break, so it gotta stay I guess.Right. And at the end of the day it works correctly in the context of the hwcontext. You might feed into some theoretical filter that would handle it appropriately. Just because nvenc can't actually consume it fully doesn't make it wrong. --phil _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
