topic Re: Request key frame in vpuenc in i.MX Processors

Request key frame in vpuenc

jjardon — Fri, 27 Sep 2013 00:35:52 GMT

Hi, I need to generate a keyframe in a specific time. Looking to the code of vpuenc, seems that it doesnt handle events from downstream (GST_EVENT_CUSTOM_DOWNSTREAM) to check if the event request a keyframe: gst_video_event_is_force_key_unit (event) (and no, it doesnt derive from the GstVideoEncoder baseclass class) This can be easily implementable but my question is: Any of you know the specific option I have to pass to the vpu to generate a keyframe? Or any other way? I read about encparam->forceIPicture , but Im not sure Im looking in the correct direction Could someone help me with this? Thanks

Re: Request key frame in vpuenc

karina_valencia — Tue, 01 Oct 2013 17:11:14 GMT

juangutierrez Oct 1, 2013 9:40 AM (in response to jamesbone)

My initial guess is that setting the forceIPicture parameter is in the right way.

I or Intra frames are those one which are encoded regardless of the previous frames.

There is no prediction involved.

I guess keyframe refers to this type of I-frame

This is the description of the forceIPicture EncParam from the vpu_api_reference manual:

"If this value is 0, the picture type is determined by the VPU according to the

various parameters such as encoded frame number and GOP size.

If this value is 1, the frame is encoded as an I-picture regardless of the frame

number or GOP size, and I-picture period calculation is reset to the initial state.

For MPEG-4 and H.263, I-picture is sufficient for decoder refresh. For H.264

mode, the picture is encoded as an Instantaneous Decoding Refresh (IDR) picture.

This value is ignored if skipPicture = 1."

Re: Request key frame in vpuenc

RobertSchwebel — Tue, 01 Oct 2013 20:04:48 GMT

Hi,

we have this on our taskl ist for the near future. We are currently reworking the whole IPU/VPU kernel stack for mainline, with the camera path converted over to modern v4l2 with capabilities and media controller; all components including the VPU have been changed to mem2mem devices, and we also have a generic GStreamer plugin which wraps mem2mem devices. With that setup, it is not necessary to have a custom gst element for the VPU any more - it is just another mem2mem device (like i.e. the scaler).

It will probably need some time until the patches are ready for mainline; project customers usually get early access to the wip code.

rsc

Re: Request key frame in vpuenc

dv1 — Wed, 02 Oct 2013 14:05:31 GMT

This is very interesting. I have been working on GStreamer 1.0 plugins for the imx VPU and IPU (link: dv1/gstreamer-imx · GitHub ) , and stumbled upon several such issues (for example, the IPU headers reside in the kernel, the ipu-lib is not usable with the imx6..) But from what you describe, these plugins won't be necessary with mem2mem.

So your changes will make the VPU work on top of V4L , do I understand this correctly? Will you make use of dmabuf there, and remove the physical addresses? And, how will the Vivante GPU's direct textures be integrated? (They can directly render from a physical address, making them useful for video playback) I guess ideally the drivers would be modified to use EGL_image instead, and a v4l <-> EGL_image bridge.

Re: Request key frame in vpuenc

mtx512 — Tue, 15 Oct 2013 19:10:42 GMT

Hi, I'm working towards a functioning Ubuntu 13.04 build with GPU/VPU support, are your 1.0 plugins usable?

Re: Request key frame in vpuenc

dv1 — Wed, 05 Mar 2014 00:39:23 GMT

Hi, sorry for the late reply, I never got any notification about your response.

They are usable, yes. Are you by any chance already in Freenode #cubox ? I have seen a "jas-hacks" user there sometimes.