IMX Scaler / CSC m2m driver.

[Ian Molton]

Oh, some more info:

My best (so far) pipeline:

gst-launch-1.0 filesrc location= Downloads/big_buck_bunny_1080p_h264.mov ! qtdemux ! h264parse ! v4l2video3videodec capture-io-mode=dmabuf ! v4l2video0convert output-io-mode=dmabuf-import ! video/x-raw,width=480,height=272 ! ximagesink sync=false

As I understand things so far:

* filesrc read data into a buffer that qtdemux uses (no copy?)
* qtdemux fills another buffer that h264parse uses (no copy?)
* h264parse fills another buffer (no copy?)
* v4l2video3dec copies [in userspace] that last buffer to the
   buffers it gets from the kernel.
* v4l2videoconvert gets the completed buffers from v4l2video3dec
   via dmabuf-import (no copy?) and produces the scaled/CSC'd output.

Im a bit hazy on what happens next. Where does v4l2videoconvert get
its output (capture?) buffers from? presumably they arent the same
ones it used for input as the sizes wont [necessarily] match?

if these are allocted in ximagesink, and passed in from there, then
it would need capture-io-mode=userptr is that right?

presumably without USERPTR, the buffers would have been allocated
in kernel (via ?), and would need to have been copied to userspace?

I did notice some /really/ odd behaviour from this pipeline:

gst-launch-1.0 filesrc location= Downloads/big_buck_bunny_1080p_h264.mov ! qtdemux ! h264parse ! v4l2video3videodec capture-io-mode=dmabuf ! v4l2video0convert output-io-mode=userptr ! video/x-raw,width=1920,height=1088 ! ximagesink sync=false

with the video going back in time, etc. (actually, I think I could
see the IPU IC tiling, as it seemed like there were 4 regions of the
display, and not always in sync with each other.)

-Ian