Hi everyone,
I'm running Yocto on a custom i.MX6 board and trying to loop a video using playbin2. I've attached to playbin2's "about-to-finish" signal as follows:
g_signal_connect(playbin2, "about-to-finish", G_CALLBACK(prepare_next_stream), (gpointer)ba.constData()); |
where ba.constData() returns a static array containing the filename to play. And here's the callback function I'm using:
void prepare_next_stream(GstElement *obj, gpointer uri)
{
qDebug() << "Prep next stream Marlon!" << (const char*) uri;
//gst_element_set_state(obj,GST_STATE_READY);
g_object_set (obj, "uri", (const char*) uri, NULL);
//gst_element_set_state(obj,GST_STATE_PLAYING);
}
This works, but only every second time the video is played. The video will play correctly, start to play and then freeze for the duration the video should be, and then start over and play the video correctly.
is this a bug in GStreamer? Is there a workaround for this?
Update: After enablning debug output, I see this message constantly when the problem occurs:
0:00:31.162584338 1176 0x5eac00 WARN | mfw_v4lsink mfw_gst_v4l_buffer.c:435:mfw_gst_v4l2_new_buffer: Try new buffer failed, ret 0 Success queued 1 |
0:00:31.215699672 1176 0x5eac00 WARN | vpudec vpudec.c:915:gst_vpudec_core_create_and_register_frames: Allocate Internal framebuffers!!!! |
0:00:31.250310672 1176 0x33f07600 WARN | mfw_v4lsink mfw_gst_v4lsink.c:1183:mfw_gst_v4lsink_show_frame: Drop because no reserved hwbuffer2 |
0:00:31.283367672 1176 0x33f07600 WARN | mfw_v4lsink mfw_gst_v4lsink.c:1183:mfw_gst_v4lsink_show_frame: Drop because no reserved hwbuffer2 |
0:00:31.316680005 1176 0x33f07600 WARN | mfw_v4lsink mfw_gst_v4lsink.c:1183:mfw_gst_v4lsink_show_frame: Drop because no reserved hwbuffer2 |
0:00:31.349995338 1176 0x33f07600 WARN | mfw_v4lsink mfw_gst_v4lsink.c:1183:mfw_gst_v4lsink_show_frame: Drop because no reserved hwbuffer2 |
0:00:31.383467005 1176 0x33f07600 WARN | mfw_v4lsink mfw_gst_v4lsink.c:1183:mfw_gst_v4lsink_show_frame: Drop because no reserved hwbuffer2 |
Thanks
Marlon
I found two other threads on this forum about problems with gst_element_seek(), but none of the problems have been solved:
I've just finished a test program which consistently demonstrates the problem. I've attached it to this email along with a video I'm using for testing. I've been running it with GST_DEBUG=2 to see the error messages.
Currently it will play the video correctly the first time, but every subsequent loop is played at the wrong speed with a bunch of messages about dropped buffers. You can also comment out line 23 to try and seek the video on EOS instead of using the about-to-finish signal; this method also does not work consistently.
The test video we're using was created with mencoder using the following command line:
mencoder -endpos 00:00:07 -nosound -of rawvideo -ofps 30 -vf harddup -ovc copy ./input.avi -o ./test.264
The resulting format is a raw h.264 video stream; we must use this format to maintain compatibility with another one of our products.
Hi Marlon,
Experts are waiting for your reply to the provided suggestions and to the additional questions.
Do you have any additional feedback that you would like to share?
Best regards!
/Carlos
Hi Carlos, sorry for not getting back to you sooner! I didn't see your messages until today. To answer your questions:
1. Switching to a newer version of Yocto requires porting the board support package, and the kernel in the latest version of Yocto is configured with a different method than the one in Dora. This means a lot of new development, and it means that we'll have to deal with new bugs as many of the software packages have been updated.
2. If I call set_state(), there is a pause in the video playback. I need the video to loop without a pause.
3. Seek does not work. Videos will sometimes fail to seek, and then playback will freeze.
I'll try to provide some debug information when seek fails, but I don't see any error output when it happens. All I know is that gst_element_seek() returns false. There are no error messages print on the console when the seek fails.
Hi Marlon,
Experts are reviewing your case. In the mean time, they sent some suggestions and questions:
What is your use case? Which kind of implement is your expect?
Hope this information will be useful for you.
Best regards!
/Carlos
Hi Marlon,
I have internally asked for solutions to similar issues. I will post additional details here as soon as getting news.
Best regards!
/Carlos
Hi Marlon,
You could take a look at the following documents from Freescale Community:
https://community.freescale.com/docs/DOC-93445
https://community.freescale.com/docs/DOC-93451
https://community.freescale.com/docs/DOC-93446
Additionally, on the following blog you could find an example of looping back with GStreamer:
http://tristanswork.blogspot.com/2010/10/looping-playback-with-gstreamer.html
Hope this will be useful for you.
Best regards!
/Carlos
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Thanks for the reply Carlos. I have tried the solution on that blog, but some videos do not seek correctly and simply stop playing instead of looping. I have also seen those documents but they do not give examples for looping. I have also tried mfw_isink instead of mfw_v4lsink, which works for some videos but for others causes a different error:
0:01:16.471587677 915 0x5ee2c0 WARN | vpudec vpudec.c:1859:gst_vpudec_sink_event: Unsupport n |
ewsegment format 2
[INFO] bitstreamMode 1, chromaInterleave 1, mapType 0, tiled2LinearEnable 0
[WARN] VPU iram is less than needed, some parts don't use iram
0:01:16.523647678 915 0x5ee290 WARN | basesink /home/marlon/work/CSI/Table_Limit/LCD_Table_Limi |
t/New_Table_Limit/i.MX6/release/build_0.02/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnuea
bi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasesink.c:2875:gst_base_sink_is_too_late:<mfwgstisin
k0> warning: A lot of buffers are being dropped.
0:01:16.523919011 915 0x5ee290 WARN | basesink /home/marlon/work/CSI/Table_Limit/LCD_Table_Limi |
t/New_Table_Limit/i.MX6/release/build_0.02/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnuea
bi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasesink.c:2875:gst_base_sink_is_too_late:<mfwgstisin
k0> warning: There may be a timestamping problem, or this computer is too slow.
0:01:16.644650678 915 0x5ee290 WARN | basesink /home/marlon/work/CSI/Table_Limit/LCD_Table_Limi |
t/New_Table_Limit/i.MX6/release/build_0.02/fsl-community-bsp/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnuea
bi/gstreamer/0.10.36-r2/gstreamer-0.10.36/libs/gst/base/gstbasesink.c:2875:gst_base_sink_is_too_late:<mfwgstisin
k0> warning: A lot of buffers are being dropped.