Hi! 2016-08-24 9:41 GMT+02:00 Oliver Collyer <ovcoll...@mac.com>: > >> On 23 Aug 2016, at 21:21, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >> >> 2016-08-23 19:10 GMT+02:00 Oliver Collyer <ovcoll...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
