On 2017-01-31 07:45, wm4 wrote:
On Tue, 31 Jan 2017 15:38:33 +0000
Sumit Agarwal <sum...@nvidia.com> wrote:
From 0d6be9eebacc4403ecd7677e89c3205892b8809b Mon Sep 17 00:00:00 2001
From: sumit <sum...@nvidia.com>
Date: Tue, 31 Jan 2017 21:00:50 +0530
Subject: [PATCH] Add 420 10-bit transcode support for hwaccel cuvid
---
ffmpeg_cuvid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffmpeg_cuvid.c b/ffmpeg_cuvid.c
index 766878f..baf6eee 100644
--- a/ffmpeg_cuvid.c
+++ b/ffmpeg_cuvid.c
@@ -135,7 +135,7 @@ int cuvid_transcode_init(OutputStream *ost)
*/
hwframe_ctx = (AVHWFramesContext*)ctx->hw_frames_ctx->data;
hwframe_ctx->format = AV_PIX_FMT_CUDA;
- hwframe_ctx->sw_format = AV_PIX_FMT_NV12;
+ hwframe_ctx->sw_format = ist->st->codecpar->format ==
AV_PIX_FMT_YUV420P10 ? AV_PIX_FMT_P010 : AV_PIX_FMT_NV12;
}
return 0;
This relies on the format reported by the demuxer, which may or may not
work, depending on what the parser or decoder ran by libavformat does.
It might work on most cases, but it's still a bad idea.
The right way to implement this is letting cuvid parse the codec data
(e.g. SPS), and then use the values reported by it.
IIRC, past conversations on this have concluded that the 'avconv'
rewrite will allow this by
avoiding the current problem that the encoder is fully initialised up
front before the cuvid
parser can run. Presumably, at some point in the future, we'll get
through the merge backlog
and eventually get that in.
In the meantime, I'm ok with this change. In the cases where the format
is set correctly it
will help, and in the cases where it is not set, it will degrade to the
current behaviour.
As such it's strictly an improvement.
--phil
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
