seek stop problem
Locked
 
|
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 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 [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
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; > } > 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 > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
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 <[hidden email]> 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 >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
On Wed, 2012-03-21 at 22:03 +0100, Sergei Vorobyov wrote:
Hi, you should just file a bug against the demuxer(s) in question really, it should be fixed, and it shouldn't be too much work. Cheers -Tim _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Sergei Vorobyov
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 <[hidden email]> 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 >>> [hidden email] >>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
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 <[hidden email]> 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 <[hidden email]> 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 >>>> [hidden email] >>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>> _______________________________________________ >>> gstreamer-devel mailing list >>> [hidden email] >>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |