imx6 / mainline linux / basic problems

[Ian Molton]

On 05/02/15 13:11, Carlos Rafael Giani wrote:
> This confirms that the videoconvert element is the culprit. You are
> correct that videoconvert gets into a passthrough mode because it
> does not have to convert anything (fakesink accepts any caps). Try
> this for example: gst-launch-1.0 filesrc location=
> /home/ian/Downloads/big_buck_bunny_1080p_h264.mov ! qtdemux !
> h264parse ! queue ! v4l2video5dec ! videoconvert ! "video/x-raw,
> format=RGBA" ! fakesink sync=false

This results in a slow playback - exactly as suspected :-)

> Oh, and what's with the v4l2video1dec, v4l2video5dec etc. names?

They are, apparently, how its done... I don't like it, as it broke
spectacularly when I added a new device in /dev/video. I would have
thought a better way than a dynamically renaming plugin would be
v4l2videodec in=/dev/videoX, out=/dev/videoY (or surely it can
autoprobe based on information in /sys?)

On further investigation, I've now got some sort of hardware colourspace conversion working. I didn't realise before, but you gave me the idea to try this:

gst-launch-1.0 -v filesrc location= /home/ian/Downloads/big_buck_bunny_1080p_h264.mov ! qtdemux ! h264parse ! queue ! v4l2video5dec ! queue ! v4l2video0convert ! "video/x-raw, format=RGB16" ! fbdevsink sync=false

for some reason, v4l2video0convert doesn't seem to negotiate correctly with fbdevsink. But sometimes it does, which confuses me.

I've also upped the framebuffer to 32bpp, which has, sadly, made it all slower. And added random black screenings to the mix, which might have something to do with the messages:

[  631.047859] imx-ipuv3-scaler imx-ipuv3-scaler.10: Timeout waiting for scaling result
[  631.736821] imx-ipuv3 2400000.ipu: Timeout waiting for DMFC FIFOs to clear

?

-Ian