[FFmpeg-devel] [PATCH] Nvidia NVENC 10-bit HEVC encoding and rate control lookahead support

Carl Eugen Hoyos ceffmpeg at gmail.com
Wed Aug 24 10:50:28 EEST 2016


Hi!

2016-08-24 9:41 GMT+02:00 Oliver Collyer <ovcollyer at mac.com>:
>
>> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>
>> 2016-08-23 19:10 GMT+02:00 Oliver Collyer <ovcollyer at mac.com>:
>>> +    AV_PIX_FMT_YUV420P10LE,
>>
>> I know this is theoretical but the Nvidia header seems to indicate
>> native endianness to me, so this should be AV_PIX_FMT_YUV420P10
>>
>>> +    AV_PIX_FMT_YUV444P10LE
>>
>> But after reading the rest of the patch:
>> Shouldn't this be AV_PIX_FMT_YUV444P16?

(Thanks for testing this!)

>> And instead of YUV420P10, shouldn't you use P010LE?
>>
>
> So I’ve tried with P010 but ran into a problem in that this pixel format is
> only supported as an input format.
>
> In my test I’m reading a yuv420p file and then specifying -pix_fmt P010
> but this is giving an error message saying the conversion is impossible.
> ffmpeg -pix_fmts confirms it is only valid as an input format.

Sorry for not realizing this originally!

> Of course, if the source is P010 then presumably there is no problem.

> What should I do? Maybe support both P010 so that if someone has a
> source in this format it can be encoded natively but also support
> YUV420P10 with my conversion/shifting routine?
>
> Or should I just support P010 and then consider it a limitation of FFmpeg
> that it cannot convert a different format to this one?

Imo, both are ok (and the first obviously makes more sense) but wait for
> others to comment.

The ideal solution is of course if you port your conversion routine to
libswscale
(but this will need a little effort I guess and should imo not block
your patch).

Carl Eugen


More information about the ffmpeg-devel mailing list