Freescale's hardware accelerated h264 codec

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Freescale's hardware accelerated h264 codec

23,075件の閲覧回数
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 返答(返信)

3,408件の閲覧回数
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 件の賞賛
返信

3,408件の閲覧回数
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 件の賞賛
返信

3,408件の閲覧回数
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 件の賞賛
返信

3,408件の閲覧回数
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 件の賞賛
返信

3,408件の閲覧回数
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 件の賞賛
返信

3,408件の閲覧回数
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 件の賞賛
返信

3,408件の閲覧回数
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 件の賞賛
返信

3,408件の閲覧回数
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 件の賞賛
返信

3,409件の閲覧回数
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 件の賞賛
返信

3,409件の閲覧回数
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 件の賞賛
返信

3,411件の閲覧回数
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 件の賞賛
返信

3,410件の閲覧回数
rostislav
Contributor III

Both pipelines run on the same machine.

0 件の賞賛
返信

3,410件の閲覧回数
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 件の賞賛
返信

3,410件の閲覧回数
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 件の賞賛
返信

3,410件の閲覧回数
rostislav
Contributor III

Leonardo,

Could you please recommend some documents regarding the codecs?

0 件の賞賛
返信

3,410件の閲覧回数
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 件の賞賛
返信