IMX Scaler / CSC m2m driver.
Ian Molton
imolton at ad-holdings.co.uk
Wed Mar 25 08:04:43 PDT 2015
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
More information about the gstreamer-devel
mailing list