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

[Oliver Collyer]

> On 24 Aug 2016, at 10:50, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 
> 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).
> 

Ok, I’ll wait for more feedback.

There is a certain logic in supporting both since the patch then neatly adds 10-bit support for all the existing 8-bit formats it currently supports:

i.e. currently it supports...

YUV420P
NV12
YUV444P

…which would become

YUV420P
YUV420P10
NV12
P010
YUV444P
YUV444P16

This appeals to my sense of symmetry :)

Regards

Oliver

> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel