[FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

[Philip Langdale]

On 2017-01-31 07:45, wm4 wrote:
> On Tue, 31 Jan 2017 15:38:33 +0000
> Sumit Agarwal <sumita at nvidia.com> wrote:
> 
>> From 0d6be9eebacc4403ecd7677e89c3205892b8809b Mon Sep 17 00:00:00 2001
>> From: sumit <sumita at 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