I've written a video player in C++ (Qt 4.8.4) which uses Gstreamer 0.10 and the Freescale aiurdemux plugin 3.0.7. It's running on Timesys' BSP for the Nitrogen6X board, Linux version 3.0.35-ts-armv7l. CPU: i.MX6Q, 1GB RAM. Videos are being played from an attached 1TB SATA 2.5" drive. The video format I'm using is MPEG-2 TS (transport stream) and encoded using H.264.
I'm trying to add fast-forward and rewind functions to the player and notice some strange intermittent behavior. When I increase the playback speed to 4 (fast-forward) or -4 (rewind), much of the time the player works fine. But sometimes I get the following error from Gstreamer:
GStreamer-CRITICAL **: gst_segment_set_seek: assertion `start <= stop' failed
This is happening when I'm trying to return to the normal playback speed of 1. I've checked my start and stop values and they are fine so I shouldn't be seeing this assertion error. When I get this error, the video continues at its current playback speed of 4 or -4. After repeated attempts of changing the playback speed, Gstreamer will eventually return to a rate of 1.
My code for changing playback speed is based on this Gstreamer tutorial: http://docs.gstreamer.com/display/GstSDK/Basic+tutorial+13%3A+Playback+speed
I've looked through the Gstreamer mailing list and someone mentioned this error is a bug but that was back in 2011. I would think it has been fixed by now...
Any ideas why this happens and how to fix it?
Thanks,
Jim
已解决! 转到解答。
Thanks Eric for the link to Yocto. I'll give that a try because it may solve our other open issue where Gstreamer fails to allocate enough contiguous memory to play a video: GStreamer crashing on i.MX6 (Boundary Devices Nitrogen6x)
Leonardo: That was a good idea having me try gplay; I didn't have the error when I used that program.
I looked at the source code to see how it was accomplished. It looks like the Gstreamer tutorial I referenced in my initial post has a mistake. Specifically this line:
seek_event = gst_event_new_seek (data->rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE, GST_SEEK_TYPE_SET, position, GST_SEEK_TYPE_NONE, 0);
here's the gplay version:
set_playback_rate_event = gst_event_new_seek(playback_rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT, GST_SEEK_TYPE_SET, current_position, GST_SEEK_TYPE_SET, pproperty->duration);
So I think the last two parameters are what was causing my problem. I used GST_SEEK_TYPE_NONE and zero. After changing it to GST_SEEK_TYPE_SET and the duration of the video, I no longer experienced the error.
Thanks again,
Jim
Jim, can you do the same test using 3.0.9 or 3.0.10 version? On Yocto, the community dora brances are using gst-fsl-plugin_3.0.9 and master-next 3.0.10. Also, if you can duplicate the issue using just gplay, it would be great.
Hi Jim,
You can get a Dora release (w/3.0.9 gstreamer components) from here:
http://boundarydevices.com/yocto-dora-release-mx6/
We don't have an image on-line with the 3.10.17 (3.0.10) versions.
You'd have to build with master-next, but kernel support is present.
Thanks Eric for the link to Yocto. I'll give that a try because it may solve our other open issue where Gstreamer fails to allocate enough contiguous memory to play a video: GStreamer crashing on i.MX6 (Boundary Devices Nitrogen6x)
Leonardo: That was a good idea having me try gplay; I didn't have the error when I used that program.
I looked at the source code to see how it was accomplished. It looks like the Gstreamer tutorial I referenced in my initial post has a mistake. Specifically this line:
seek_event = gst_event_new_seek (data->rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_ACCURATE, GST_SEEK_TYPE_SET, position, GST_SEEK_TYPE_NONE, 0);
here's the gplay version:
set_playback_rate_event = gst_event_new_seek(playback_rate, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_KEY_UNIT, GST_SEEK_TYPE_SET, current_position, GST_SEEK_TYPE_SET, pproperty->duration);
So I think the last two parameters are what was causing my problem. I used GST_SEEK_TYPE_NONE and zero. After changing it to GST_SEEK_TYPE_SET and the duration of the video, I no longer experienced the error.
Thanks again,
Jim