IMX Scaler / CSC m2m driver.

[Philipp Zabel]

Am Mittwoch, den 25.03.2015, 11:33 -0400 schrieb Nicolas Dufresne:
> Le mercredi 25 mars 2015 à 15:04 +0000, Ian Molton a écrit :
> > 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?)
> 
> Well, reading from file to ram is usually considered a copy. Though
> encoded data is 40 times smaller generally.
> 
> > * qtdemux fills another buffer that h264parse uses (no copy?)
> 
> qtdemux will frame and parse the output. It may requires copies.
> 
> > * h264parse fills another buffer (no copy?)
> 
> In this case no copy, it will only copy is very special conditions.
> 
> > * v4l2video3dec copies [in userspace] that last buffer to the
> >    buffers it gets from the kernel.
> 
> A copy is made to the device mmap pool. This is only avoidable if your
> driver supports output-io-mode=userptr. demuxers don't do allocation
> query, so they can't write into the decoder pool.
> 
> > * v4l2videoconvert gets the completed buffers from v4l2video3dec
> >    via dmabuf-import (no copy?) and produces the scaled/CSC'd output.
> 
> No copy, and no CPU mampping (mmap). That makes the expensive flush
> suspicious btw.

That is a bug in the coda driver, there is a leftover cache flush of the
bitstream buffer, even though it is mapped write-combine. I'll send a
patch.

> > 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.)

The scaler hardware does not support userptr memory, the mem2mem driver
is wrong to advertise it.

regards
Philipp