On 1/22/17 11:13 AM, Philip Langdale wrote:
On Sat, 21 Jan 2017 10:27:30 -0700
pkoshe...@gmail.com wrote:
From: Pavel Koshevoy <pkoshe...@gmail.com>
Evidently CUVID doesn't support decoding 422 or 444 chroma formats,
and only a limited set of resolutions per codec are supported.
Unfortunately CUVID silently drops packets for video of unsupported
resolution. However, it will error-out at cuvidCreateDecoder call
if the indicated video resolution is not supported.
Given that stream resolution and pixel format are typically known as
a result of probing it is better to use this information during
avcodec_open2 call to fail immediately, rather than proceeding to
decode and never receiving any frames from the decoder nor receiving
any indication of decode failure.
So I'm confused. I agree that these errors do not emerge early enough
to induce failure at decoder init time, but they should all trigger
errors at first-frame decode time. That's certainly true for the
chroma format error, because I added that logic.
Assuming that is true, you should just be dealing with first-frame
failure and then falling back to SW decoding, or whatever policy
you want in your app (I assume 8K SW decoding won't go well...).
Yeah, but I don't even get a 1st frame failure with YUV420P 8K from
h264_cuvid -- all I ever get is a 0 from avcodec_send_packet and
AVERROR(EAGAIN) from avcodec_receive_frame. This is what I've observed
with GeForce GT 730 and GeForce GTX 1060 on openSUSE 42.2 and Ubuntu
16.04 with latest nvidia drivers.
I will try to make my application more robust too -- I will have to
buffer all the packets sent to the decoder until the 1st frame either
succeeds or fails, so I can re-send the same packets to another decoder
in case of 1st frame failure.
Pavel.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
