IMX Scaler / CSC m2m driver.

[Ian Molton]

Hi all,

Thanks for all your help, guys!

I've applied the patches Philipp posted to linux-media yesterday,
and built the gstreamer plugin from Jean-Michels
repo: https://github.com/Vodalys/gst-plugins-good

I'm not clear if I should be using Philipps or Steves version of
the kernel stuff here. For now, I'm using Philips, as its the most
recent I have, and it appeared to work first time.

I can now run the following pipeline:

gst-launch-1.0 filesrc location= Downloads/big_buck_bunny_1080p_h264.mov ! qtdemux ! h264parse ! queue ! v4l2video3videodec ! queue ! v4l2video0convert ! video/x-raw,width=1920,height=1080 ! ximagesink sync=false

And see video on the screen - and its noticeably faster than:

gst-launch-1.0 filesrc location= Downloads/big_buck_bunny_1080p_h264.mov ! qtdemux ! h264parse ! queue ! v4l2video3videodec ! queue ! videoscale ! video/x-raw,width=1920,height=1080 ! videoconvert !ximagesink sync=false

About 2-3x as fast. To be more precise,

I get:
  5.5 FPS @ 1980x1080
10.5 FPS @ 960x540
13.0 FPS @ 640x320
13.6 FPS @ 540x320
13.7 FPS @ 540x300 , 540x280

attempting to go to 540x270 resulted in a flashing green /
black window, accompanied by the following in dmesg:

imx-ipuv3-scaler imx-ipuv3-scaler.4: Timeout waiting for scaling result

...followed about 30 seconds later by a fairly spectacular oops, which I
didn't manage to catch anything useful from, and a (soft) system lockup.
(serial still works, but its all oops). HDMI still shows a display,
usually, but on one occasion it killed HDMI too. Refcounting / locking
issue?

I've also noticed that on some occasions the pipeline refused to run, but
choosing different resolutions (and then going back to the one I wanted)
seemed to fix it - possibly something uninitialised somewhere?

=================

For comparison, the following are for hardware decode, but with software
scaling + CSC:

2.2FPS @ 1920x1080
4.8FPS @ 960x540
8.5FPS @ 540x320
23.9FPS @ 180x90
31.3FPS @ 120x50

And also with no output / scaling / transform:

42FPS, straight out of the decode element.

CPU utilisation doing software decode is ~120-130% compared to ~100% for
the pipeline above. Although with sync=false, I'm not sure how meaningful
that is...

The above figures seem to suggest that the hardware pipeline is
bottlenecked somewhere, since its figures seem to be levelling out
as resolution decreases.

Any thoughts on where to start looking? I can see if I can get more
profiling on this.

-Ian