On 01/22/2017 04:58 AM, wm4 wrote:
On Sat, 21 Jan 2017 10:35:50 -0700
Pavel Koshevoy <pkoshe...@gmail.com> wrote:
On Sat, Jan 21, 2017 at 10:27 AM, <pkoshe...@gmail.com> wrote:
From: Pavel Koshevoy <pkoshe...@gmail.com>
<snip>
- ret = cuvid_test_dummy_decoder(avctx, &ctx->cuparseinfo);
+ ret = cuvid_test_dummy_decoder(avctx, &ctx->cuparseinfo,
+ probed_chroma_format,
+ probed_width,
+ probed_height);
if (ret < 0)
goto error;
--
2.9.2
Despite wm4 objections I am resubmitting this patch, because I can
find no other reasonable method for rejecting ffmpeg cuvid decoder
when it can't handle a given video stream. An unreasonable
alternative would be to duplicate the work that cuvid.c does
internally on my application side, and that would be of little benefit
to me and to ffmpeg -- I might as well use the nvenc APIs directly
then. I still see this patch as an improvement.
PS:
Actually, cuvid is a bit different from normal hwaccel and I confused
that (blame Sunday "morning").
In this case, do you just want the cuvid to gracefully exit the ffmpeg.c
process if decoding is not supported? In that case, this would be much
simpler:
1. Return a special error code from cuvid that signals unsupported
format
2. Make ffmpeg.c check for this error code, and stop transcoding with
an error if it's encountered
I am not working with ffmpeg.c -- I am calling ffmpeg public APIs from my
application. The 1. point above is essentially what my patch does. The real
problem is that CUVID only reports an error at cuvidCreateDecoder time, and not
later when I attempt to decode 8K or 5K video -- it just swallows packets and
never outputs anything (no errors, no callbacks, nothing).
Pavel.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
