seek stop problem

Sergei Vorobyov sergei.vorobyov at facilitylabs.com
Mon Mar 26 05:22:15 PDT 2012


Thank you very much, Stefan!

1) seeks from within callbacks (as discussed below) work just fine, as expected;

2) running random seeks on a long gnlcomposition for a few days also
works fine (no memory leaks, no difference in CPU usage); only one
laptop becomes slow-responsive after 8-10 hours of playing; strangely,
it shows the same CPU and memory use indications. I think this is a
screensaver/graphics card issue, unrelated to GStreamer.

However (there was a similar question on the list a few days back),
playing mp4 files takes twice 27-35% of 2 cpu cores of my 8-core Intel
Core i7 2.8GHz.

Is there any way to use nVidia graphics card acceleration? Currently I
am using ximagesink; xvimagesink and autovideosink fare a bit better,
up to 2 x 20% cpu cores.

(Maybe I am just fooling myself and this CPU time is used for
*decoding*, not image rendering?)

Besides, dfbimagesink, glsink mentioned in the manual apparently do
not exist (by gst-inspect, glsink is not even in the list of all
plugins), and dfbvideosink reports "could not open resource for
writing".

On Thu, Mar 22, 2012 at 10:06 AM, Stefan Sauer <ensonic at hora-obscura.de> wrote:
> On 03/21/2012 10:03 PM, Sergei Vorobyov wrote:
>> Indeed, I just complemented
>>
>> GST_SEEK_FLAG_FLUSH,
>>
>> below with the segment flag
>>
>> GST_SEEK_FLAG_FLUSH | GST_SEEK_FLAG_SEGMENT,
>>
>> and now
>>
>>  if (msg_type & GST_MESSAGE_SEGMENT_DONE) {
>>       g_print ("SEGMENT DONE message\n");
>>       g_main_loop_quit (loop);
>>       return TRUE;
>> }
>>
>> in my callback stops the stream after 5 seconds, as intended.
>>
>> Many thanks, Stefan!
>>
>> I just wanted to repeat my question: is it better to:
>>
>> 1) call g_main_loop_quit (loop) in the callback and iterate for(;;) {
>> ... g_main_loop_run (loop); ...} or
>>
>> 2) making the seek inside the callback, never calling g_main_loop_quit
>> (loop) and (top-level) calling g_main_loop_run (loop) just once?
>>
>> I mean, what is the canonical/preferred way?
>
> It is completely fine to just seek from the segment-done callback. No
> need to stop the main-loop.
>
>> I noticed that using alternative 1) when I leave my random player work
>> overnight, it does not leak memory (about 2.5% of 3GB), but the
>> computer becomes *completely* irresponsive (it takes about a minute to
>> echo every keystroke) and I have to reboot. (Of course, this may be
>> caused by my own other remaining errors).
> No idea about that. Maybe you can investigate a bit further. Also
> consider publishing it somewhere so that people can retry that fro themself.
>
> Stefan
>
>> Best regards,
>> Sergei
>>
>> On Wed, Mar 21, 2012 at 9:15 PM, Stefan Sauer <ensonic at hora-obscura.de> wrote:
>>> On 03/21/2012 02:29 PM, Sergei Vorobyov wrote:
>>>> Greetings,
>>>>
>>>> I am experiencing the following problem with stopping the playback in:
>>>>
>>>> for (;;) {
>>>>
>>>> /* random position ps in nanoseconds (out of 10 possibilities 0,
>>>> 5000000000, 10000000000, ..., 45000000000) is generated */
>>>>
>>>> event = gst_event_new_seek (1.0,
>>>>                                 GST_FORMAT_TIME,
>>>>                                 GST_SEEK_FLAG_FLUSH,
>>>>                                 GST_SEEK_TYPE_SET, ps,
>>>>                                 GST_SEEK_TYPE_SET, ps + 5 * GST_SECOND);
>>>>
>>>> result = gst_element_send_event(pipeline, event);
>>>>
>>>> /* see the insert below */
>>>>
>>>> g_main_loop_run (loop);
>>>>
>>>> }
>>>>
>>>> My intention is to play a random 5-sec segment.
>>>>
>>>> The seek to the initial position ps is accurate, but the playback does
>>>> not stop after 5 secs as intended (and specified in the APIs); it goes
>>>> to the very end, until EOS is generated, caught in my callback
>>>> function, which calls
>>>>
>>>> if (msg_type & GST_MESSAGE_EOS) {
>>>>       g_print ("EOS message\n");
>>>>       g_main_loop_quit (loop);
>>>>       return TRUE;
>>>> }
>>>>
>>> I don't think demuxer actually implement that. You could set the SEGMENT
>>> flag and listen to SEGMENT_DONE next to EOS.
>>>
>>> Stefan
>>>
>>>> I checked and caught all signals in my callback function, and
>>>> SEGMENT_DONE or anything relevant never occur, except EOS in the very
>>>> end.
>>>>
>>>> I tried another possibility. Rather than relying on (non-working)
>>>> terminating ... GST_SEEK_TYPE_SET, ps + 5 * GST_SECOND); above
>>>>
>>>> I inserted, before g_main_loop_run (loop); instead /* see the insert below */
>>>>
>>>> the following timeout call
>>>>
>>>> g_timeout_add_seconds (5, (GSourceFunc) cb_end_stream, pipeline);
>>>>
>>>> with the trivial callback
>>>>
>>>> gboolean cb_end_stream (GstElement *pipeline)
>>>> {
>>>>   g_main_loop_quit(loop);
>>>>   return FALSE;
>>>> }
>>>>
>>>> Now, it stops the playback accurately, always after 5 secs, but
>>>> initial position seeks sometimes err (usually 10 secs later than
>>>> asked).
>>>>
>>>> Maybe I forgot to mention that my pipeline is constructed using the
>>>> gnlcomposition out of ten 5-second pieces concatenated in the 50 sec
>>>> stream, which test-plays correctly and smoothly.
>>>>
>>>> I would appreciate any hints and help.
>>>>
>>>> PS:
>>>>
>>>> maybe I need to rewind the pipe withing the callback function, without
>>>> ever calling g_main_loop_quit (loop) in my callbacks? Currently I am
>>>> looping over the g_main_loop_run:
>>>>
>>>> for (;;) {
>>>> ...
>>>> g_main_loop_run (loop);
>>>>
>>>> }
>>>>
>>>> Many thanks!
>>>> _______________________________________________
>>>> gstreamer-devel mailing list
>>>> gstreamer-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel


More information about the gstreamer-devel mailing list