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
已解决! 转到解答。
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."
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
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.
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.
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."