Video and rendering performance

#1

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
#2

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

#3

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.

#4

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?

#5

I found this commit on official 4.4-repo:

I don’t know if it’s working…

1 Like
#6

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

#7

Strange that this is in official r2-repo…

where do you see it is for MT8173?

#8

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.

#9

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

#10

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
#11

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