Freescale's hardware accelerated h264 codec

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Freescale's hardware accelerated h264 codec

10,800 Views
rostislav
Contributor III

I installed the Freescale's codecs following i.MX Linux Mulimedia Framework User's Guide.


While trying to use a h264 codec we get the following error:


0:11.053 PExternalT...0x2f2be420 GStreamer mfw_gst_h264_getbuffer: >>DECODER: Error -4 in allocating the Framebuffer[0]

Could anybody point to a document that may help to interpret codec errors? What the  "Error -4" means?

I printed that question in my old thread, but I have doubts because the old thread status assumed answered. That is a reason I reprinted the question starting new thread.

57 Replies

856 Views
timothybean
Contributor IV

Robert,

You should use /dev/video16 for the GUI (Ubuntu) and /dev/video17 for the video. But, the ALPHA is hard coded in mfw_v4lsink gstreamer element. I am not sure how to change this from outside or without modifying the element. I *thought* I saw another post somewhere on the forums on how to set and environmental variable to override this.

I just modified the alpha in mfw_v4lsink source and set it to 0. That will make the video look correct. It will also not interfere with your Ubuntu GUI.

As for your resolution, your pipeline looks correct. But, possibly not showing up right if you are using /dev/video16 and the Ubuntu GUI is there?

Tim

0 Kudos

856 Views
rostislav
Contributor III

Thanks Tim,

The system has /dev/video0 and /dev/video16. No /dev/video17 is presented.

As per my understanding for Linux GUI uses /dev/fb0 (fb1 etc. may be used as well).  /dev/video0 is a camera /dev/video16 is a video output ("MXC Video Output"). What the video17 is?

0 Kudos

856 Views
juangutierrez
NXP Employee
NXP Employee

My understanding is that video17 is used as overly used for video, and I guess is the default if you don't specify the device in the mfw_v4lsink.

video16 as Tim mentioned is used by the GUI, that is why if you use video16 in your video pipeline the GUI is gone and you will need to restart the x-server

0 Kudos

856 Views
timothybean
Contributor IV

I am not sure how to add it under Ubuntu, but video16 is RGB output and video17 is YUV output. Maybe someone from Freescale can assist with how to add this. I don't use Ubunut, I build from LTIB.

Tim

0 Kudos

856 Views
juangutierrez
NXP Employee
NXP Employee

Regarding the transparency, you can use this piece of code I tested is working in imx6 too

https://community.freescale.com/docs/DOC-1518

0 Kudos

856 Views
rjongbloed
Contributor II

Thank you very much, I tried this code, with some slight modifications, and it certainly fixes the opacity problem.

Might I suggest adding and "alpha" element property to the gstreamer plugin for mfw_v4lsink?

0 Kudos

856 Views
rostislav
Contributor III

Thank you, Juan,

I supposed that display output to mfw_v4lsink has its own alpha setting and frame buffer does nothing with it. We have an opaque Ubuntu display that is visible through the transparent mfw_v4lsink created video.freescale-gstreamer-transparency-issue.jpg

0 Kudos

856 Views
rjongbloed
Contributor II

Additional to this, any idea why the following:

gst-launch mfw_v4lsrc capture-width=352 capture-height=288 ! mfw_v4lsink axis-top=100 axis-left=100 disp-width=352 disp-height=288

is full screen and not CIF sized?

0 Kudos

856 Views
LeonardoSandova
Specialist I

For the resolution issue, check this link Re: Gstreamer dual display resoultions

Regarding VSALPHA, it is a way to enable the ALPHA feature. I know this is confusing to have two video sinks, but for multiple displays in a SINGLE screen, use mfw_isink.

Leo

0 Kudos

856 Views
juangutierrez
NXP Employee
NXP Employee

Other option is that you can add the video device in the gst pipeline (I think is 16 but try with 17 too)

mfw_v4lsink device=/dev/video16

But this way probably you will need to reset the x-server to get back the Ubuntu GUI.

I guess the alpha application should do the work

0 Kudos

858 Views
LeonardoSandova
Specialist I

Hi Robert.

Yes, the pipeline you are running is valid, that is no doubt. on MX53 I have not seen any pipelines like the ones you are seeing. On MX6, there are some pipelines I have executed but using a RTP bin element, but I do not know what issues you will face on your setup; take a look here. BTW, if you got streaming working, any other issue is stopping you to advance?

Leo

0 Kudos

858 Views
rostislav
Contributor III

Both pipelines run on the same machine.

0 Kudos

858 Views
rjongbloed
Contributor II

Thank you, that has got us a bit further. Now there seems to be a transparency issue.

Do you have any additional documentation on the mfw_v4lsink?

The Linux_Multimedia_Framework_User_Guide.pdf file I have doesn't say much about it.


0 Kudos

858 Views
LeonardoSandova
Specialist I

Hi Robert,

The only information you can get comes from either the document you pointed out or typing gst-inspect to the specific element.

0 Kudos

858 Views
rostislav
Contributor III

Leonardo,

Could you please recommend some documents regarding the codecs?

0 Kudos

858 Views
LeonardoSandova
Specialist I

By codecs you mean freescale gstreamer elements? If yes, as I told Robert, only the Multimedia User Guide and gst-inspect from the command line are the sources of info.

leo

0 Kudos