2018-10-08 21:59 GMT+02:00, Timo Rothenpieler <t...@rothenpieler.org>:
>>> So, to be able to use these hardware compatible formats, we need
>>> definitions for them in ffmpeg. Right now, I need this for nvdec,
>>> but Vulkan also uses the same format definitions.
>> Sorry if this was already done and I forgot but please explain why
>> you cannot use YUV444P16 for this use-case.
>> If the only thing missing is libavfilter understanding
>> bits_per_raw_sample
>> we should add it there: It is needed in any case and would save us a few
>> pix_fmts and could speed up many use cases compared to your solution.
> It's pretty much all of ffmpeg and all client applications understanding
> it.
> First of all, bits_per_raw_sample, or an equivalent bit depth field, is
> missing from AVFrame.
> "In" avfilter it's primarily swscale I guess, but it also affects each
> and every filter supporting YUV444P16.
> Also, for encoders, it would mean they need a way to indicate what bit
> depths they can take, and that also has to be per pix_fmt they support.
> Then all of avcodec, ffmpeg.c, ... needs support for that.
> It's quite a deep rabit hole of changes with quite a good chance of
> something going horribly wrong in the process. Probably even in more
> places than just the ones mentioned here.

This may or may not be true, unfortunately my question was not
how difficult it would be to fix this mess (I don't think it is), but
why you want to add more to the mess.

What would happen if you just use YUV444P16?

Carl Eugen
ffmpeg-devel mailing list

Reply via email to