I have found a potential issue with the GStreamer 1.0 implementation of vpuenc relating to multiple instances of vpuenc. I have created a very simple gst1.0 command line that reproduces the issue:
gst-launch-1.0 videotestsrc num-buffers=100 ! tee name=d \
d. ! queue ! vpuenc ! "image/jpeg" ! filesink location=/tmp/file1.jpg \
d. ! queue ! vpuenc ! "video/x-h264" ! filesink location=/tmp/file1.avi
If I repeatedly run this, 1 in 7 or so runs result in the following:
Setting pipeline to PAUSED ...
[INFO] Product Info: i.MX6Q/D/S
====== VPUENC: 4.0.2 build on Oct 13 2015 14:35:57. ======
wrapper: 1.0.57 (VPUWRAPPER_ARM_LINUX Build on Oct 9 2015 12:52:37)
vpulib: 5.4.27
firmware: 3.1.1.46061
[INFO] Product Info: i.MX6Q/D/S
====== VPUENC: 4.0.2 build on Oct 13 2015 14:35:57. ======
wrapper: 1.0.57 (VPUWRAPPER_ARM_LINUX Build on Oct 9 2015 12:52:37)
vpulib: 5.4.27
firmware: 3.1.1.46061
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstVpuEnc:vpuenc1: GStreamer error: negotiation problem.
Additional debug info:
/gstreamer1.0-plugins-base/1.4.1-r0/gst-plugins-base-1.4.1/gst-libs/gst/video/gstvideoencoder.c(1474): gst_video_encoder_chain (): /GstPipeline:pipeline0/GstVpuEnc:vpuenc1:encoder not initialized
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
Are multiple instances of vpuenc supported? Is there anything I can do to overcome this issue?
Thanks,
Andrew Murray
Solved! Go to Solution.
Here is the fix. The fix already included in the latest release.
diff --git a/plugins/vpu/gstvpuenc.c b/plugins/vpu/gstvpuenc.c
index 73e7844..e419073 100755
--- a/plugins/vpu/gstvpuenc.c
+++ b/plugins/vpu/gstvpuenc.c
@@ -554,7 +554,7 @@ gst_vpu_enc_set_format (GstVideoEncoder * benc, GstVideoCodecState * state)
return FALSE;
}
- memset(&(enc->open_param), 0, sizeof(VpuEncOpenParam));
+ memset(&(enc->open_param), 0, sizeof(VpuEncOpenParamSimp));
if (!gst_vpu_enc_decide_output_video_format (benc)) {
GST_ERROR_OBJECT (enc, "gst_vpu_enc_decide_output_video_format fail.");
return FALSE;
I've debugged this and determined that the reason this occurs is due to corruption of the gstvideoencoder.c _GstVideoEncoderPrivate structure. This results in the value of the 'do_caps' member changing which leads to the GST_EVENT_CAPS event not being handled correctly. It seems that the majority of members in this structure become corrupt.
It seems that KevinSong has previously seen this issue (see GStreamer-devel - How to debug Gstreamer memory issue? ) and concluded the root cause was 'an invalid memory write in our hardware accelerate video encoder'.
KevinSong can you provide details of the fix for this? Is the corruption caused by the gst1.0-fsl-plugins elements or in some of the binary components such as vpulib etc? I'm not using the very latest (fsl 4.0.2 / gst 1.41) and keen to learn which component I may be able to update to resolve this.
Thanks,
Andrew Murray
Here is the fix. The fix already included in the latest release.
diff --git a/plugins/vpu/gstvpuenc.c b/plugins/vpu/gstvpuenc.c
index 73e7844..e419073 100755
--- a/plugins/vpu/gstvpuenc.c
+++ b/plugins/vpu/gstvpuenc.c
@@ -554,7 +554,7 @@ gst_vpu_enc_set_format (GstVideoEncoder * benc, GstVideoCodecState * state)
return FALSE;
}
- memset(&(enc->open_param), 0, sizeof(VpuEncOpenParam));
+ memset(&(enc->open_param), 0, sizeof(VpuEncOpenParamSimp));
if (!gst_vpu_enc_decide_output_video_format (benc)) {
GST_ERROR_OBJECT (enc, "gst_vpu_enc_decide_output_video_format fail.");
return FALSE;
Thanks for the very quick response. This has solved my issue :smileyhappy:.