On 2/12/19 3:34 AM, Philipp Zabel wrote:
Hi Steve,
On Mon, 2019-02-11 at 17:20 -0800, Steve Longerbeam wrote:
[...]
Should we support YUV BT.601 <-> YUV REC.709 conversions? That would
require separate encodings for input and output.
How about if we pass the input and output encodings to the init ic task
functions, but for now require they be the same? We can support
transcoding in a later series.
[...]
Again, I think for now, just include input/output quantization but
require full range for RGB and limited range for YUV.
Yes, that is fine. I'd just like to avoid unnecessary interface changes
between ipu-v3 and imx-media. So if we have to change it right now, why
not plan ahead.
Agreed!
But that really balloons the arguments to ipu_ic_task_init_*(). Should
we create an ipu_ic_task_init structure?
I wonder if we should just expose struct ic_csc_params
I had basically the same idea. I wasn't thinking of creating a helper to
fill in the params but sure, I'll add that.
Steve
and provide a
helper to fill it given colorspace and V4L2 encoding/quantization
parameters. Something like:
struct ipu_ic_csc_params csc;
imx_media_init_ic_csc_params(&csc,
in_cs, in_encoding, in_quantization,
out_cs, out_encoding, out_quantization);
ipu_ic_task_init(ic,
in_width, in_height,
out_width, out_height, &csc);
// or
ipu_ic_task_init_rsc(ic, rsc, &csc);
regards
Philipp
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
