Video and rendering performance

I’m currently working towards getting better performance from the graphics hardware - hardware scaling at least - but hopefully some X11 2D accelerations and GLES on the Mali 450 inside our device.

I’ve backported the latest (I could find) mtk-vcodec, mtk-jpeg mtk-mdp and mtk-vpu to 4.4.70. The code we had was old, broken and hard-coded for 64bit (v4l2 hasn’t changed much so it was just a few minor changes)

The mtk-vcodec-dec (for example) has loaded into the kernel without any problem along with all of the v4l2 dependant modules. I understand that its a v4l memory to memory decoder and ffmpeg as well as gstreamer apparently both support it.

“Video decoder, Multi-format FHD video decoding, including Mpeg1/2, Mpeg4, H.263, H.264, etc H.264 high profile 1080p@60fps”

I assume that these drivers are for the decoder/encoder functionality?

No difference in video - doesn’t look like the hardware is getting used. 2D performance via fbdev is fine for straight blits - but there’s no hook for hardware scaling.

I’m using the sunxi fbturbo X11 driver now - performance is better than the stock fbdev - but still not good enough to scale video.

Surprisingly even in the unaccelerated state - without scaling the image, it plays back 720p very smoothly (changing resolution works fine on debian - not sure why it’s stuck to 1080p on the ubuntu image - not sure why anybody would use ubuntu)

I’m going to try writing an interface (drmmode) for xf86-video-armsoc - plugging it into the mediatek DRM driver - I’ll learn more and I might have some useful information for people at the end.

1 Like

The resolution is a simple thing - the ubuntu image has an xorg.conf - it would appear that when you use your own config file - it doesn’t auto-detect everything that you don’t specify - the scanning of available modes doesn’t happen for example - so if you’re using an xorg.conf file - be sure to specify your screen modes yourself or otherwise read up on what’s going on and solve it properly

The debian versions (even in testing) of the gstreamer packages don’t include the v4l2dec plugin in the ‘good plugins’ package - so I’ll be compiling that tonight to include support - might go back to a ubuntu image if their arm packages have it - the build environment needed for gstreamer in all it’s glory? is quite extensive.

Hello, Johnny. As i see omly mtk-jpeg has support for mt7623(mt2701). vpu, vcodec, and mdp drivers are only support for MT8173.

@sinovoip Are there plans to add support for video codec?

I found this commit on official 4.4-repo:

I don’t know if it’s working…

1 Like

Didn’t tested, but. It looks very similar to 4.14 or 4.16 driver and it’s for MT8173.

Strange that this is in official r2-repo…

where do you see it is for MT8173?

For example:

static const struct of_device_id mtk_vcodec_match[] = {
	{.compatible = "mediatek,mt8173-vcodec-dec",},
	{},
};

same for mtk_vcodec_dec_drv.c, mtk-vpu, etc,etc. There are also no bindings for these devices in 7623 dts.

There is a big difference (vcodec) between 7623 and 8173 . So you cannot use the same bindings for R2.

Hi Ryder.Lee,

I got it from bpi-r2 and 8173 dts: different devices on same address. The question: is there a plan to include hw codec support to linux kernel? As I’ve discovered - there is no codec suport even in in android image. Or is there a firmeare/kernel/anything else that has it’s?

1 Like

Hi!

Is there any plans to add H.264 video decoding hardware support for MT7623N in the nearest future?

I’ve seen DTS entries for JPEG decoding - e.g. in mt7623.dtsi:

	jpegdec: jpegdec@15004000 {
		compatible = "mediatek,mt7623-jpgdec",
		     "mediatek,mt2701-jpgdec";
		reg = <0 0x15004000 0 0x1000>;
		interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_LOW>;
		clocks =  <&imgsys CLK_IMG_JPGDEC_SMI>,
			  <&imgsys CLK_IMG_JPGDEC>;
		clock-names = "jpgdec-smi",
			      "jpgdec";
		power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
		mediatek,larb = <&larb2>;
		iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
			 <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
	};

Is there any chance to see something like that for H.264?

Maybe in a form of a patch or something…

This advertised HW decoding features was part of the reason for me to buy R2 board in the fist place. (And besides HW decoding/encoding is still advertised in every spec of Banana Pi R2.) So…

(Or am I missing something and video decoding support is already there somewhere?)