seek stop problem

[Sergei Vorobyov]

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?

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).

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