From: Joshua N P. <vi...@po...> - 2002-02-25 15:16:22
|
Here is my code to seek. i added the _SET suffix to GST_SEEK_BYTEOFFSET to get it to compile with 0.3.2. static void _fv_seek (FilmView *fv, gint64 offset) { // g_warning ("seek %lld", offset); gst_pad_send_event (gst_element_get_pad (fv->cur_source->elem, "src"), gst_event_new_seek (GST_SEEK_BYTEOFFSET_SET, offset, TRUE)); } This stopped working with the upgrade from 0.3.1 to 0.3.2. Now i get: redael-filmview (pid:3503): GStreamer-ERROR **: file gstpad.c: line 1502 (gst_real_pad_dispose): assertion failed: (GST_PAD_PEER (pad) == NULL) #6 0x405a322d in g_object_unref () from /usr/lib/libgobject-1.3.so.15 #7 0x4002da0a in gst_object_unref () from /usr/lib/libgst-0.3.2.so.0 #8 0x40039b53 in gst_event_free () from /usr/lib/libgst-0.3.2.so.0 #9 0x4003fef7 in gst_pad_event_default () from /usr/lib/libgst-0.3.2.so.0 #10 0x400400b3 in gst_pad_send_event () from /usr/lib/libgst-0.3.2.so.0 #11 0x0804c099 in _fv_pause (fv=0x808d938) at filmview.c:570 It looks like there is some new ref-counting code that isn't working yet so i added a g_object_ref(pad) to see what happens next. It looks like filesrc gets stuck in g_tree_search. Program received signal SIGINT, Interrupt. 0x4060c523 in g_tree_search () from /usr/lib/libglib-1.3.so.15 (gdb) where #0 0x4060c523 in g_tree_search () from /usr/lib/libglib-1.3.so.15 #1 0x405fa595 in g_mem_chunk_alloc () from /usr/lib/libglib-1.3.so.15 #2 0x40039a29 in gst_event_new () from /usr/lib/libgst-0.3.2.so.0 #3 0x408c6f62 in gst_filesrc_get_type () from /usr/lib/gst/libgstelements.so Then a few seconds later: Program received signal SIGINT, Interrupt. 0x4060cd8a in g_tree_nnodes () from /usr/lib/libglib-1.3.so.15 (gdb) where #0 0x4060cd8a in g_tree_nnodes () from /usr/lib/libglib-1.3.so.15 #1 0x4060c58f in g_tree_search () from /usr/lib/libglib-1.3.so.15 #2 0x405fa595 in g_mem_chunk_alloc () from /usr/lib/libglib-1.3.so.15 #3 0x40039a29 in gst_event_new () from /usr/lib/libgst-0.3.2.so.0 #4 0x408c6f62 in gst_filesrc_get_type () from /usr/lib/gst/libgstelements.so Any suggestions? i noticed a brief comment in the release notes about events. It would really be nice if there was a migration guide. i don't feel too bad about API breakage if i know how to fix it. -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org |
From: Joshua N P. <vi...@po...> - 2002-02-26 06:19:21
|
On Mon, Feb 25, 2002 at 08:46:12PM +0530, Joshua N Pritikin wrote: > i noticed a brief comment in the release notes about events. It would > really be nice if there was a migration guide. i don't feel too bad > about API breakage if i know how to fix it. Hrm, i was hoping for some guidance. Do you want me to try to debug this myself? -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org |
From: Benjamin O. <in...@pu...> - 2002-02-26 08:40:29
|
Hm, I guess the reason nobody answers is that events are currently borked. We (wtay and me) were and are still thinking about a good and working way to use events. I am going to rewrite the event code nearly from scratch once I have the time. So I would be very happy if I didn't need to debug that stuff. :) And the best suggestion I can give is "don't use it or rewrite it". Sorry. I know somebody will flame me on IRC for being so negative, but oh well... Benjamin On Mon, 25 Feb 2002, Joshua N Pritikin wrote: > Here is my code to seek. i added the _SET suffix to GST_SEEK_BYTEOFFSET to > get it to compile with 0.3.2. > > static void > _fv_seek (FilmView *fv, gint64 offset) > { > // g_warning ("seek %lld", offset); > gst_pad_send_event (gst_element_get_pad (fv->cur_source->elem, "src"), > gst_event_new_seek (GST_SEEK_BYTEOFFSET_SET, offset, TRUE)); > } > > This stopped working with the upgrade from 0.3.1 to 0.3.2. Now i get: > > redael-filmview (pid:3503): GStreamer-ERROR **: file gstpad.c: line 1502 (gst_real_pad_dispose): assertion failed: (GST_PAD_PEER (pad) == NULL) > > #6 0x405a322d in g_object_unref () from /usr/lib/libgobject-1.3.so.15 > #7 0x4002da0a in gst_object_unref () from /usr/lib/libgst-0.3.2.so.0 > #8 0x40039b53 in gst_event_free () from /usr/lib/libgst-0.3.2.so.0 > #9 0x4003fef7 in gst_pad_event_default () from /usr/lib/libgst-0.3.2.so.0 > #10 0x400400b3 in gst_pad_send_event () from /usr/lib/libgst-0.3.2.so.0 > #11 0x0804c099 in _fv_pause (fv=0x808d938) at filmview.c:570 > > It looks like there is some new ref-counting code that isn't working yet > so i added a g_object_ref(pad) to see what happens next. It looks like > filesrc gets stuck in g_tree_search. > > Program received signal SIGINT, Interrupt. > 0x4060c523 in g_tree_search () from /usr/lib/libglib-1.3.so.15 > (gdb) where > #0 0x4060c523 in g_tree_search () from /usr/lib/libglib-1.3.so.15 > #1 0x405fa595 in g_mem_chunk_alloc () from /usr/lib/libglib-1.3.so.15 > #2 0x40039a29 in gst_event_new () from /usr/lib/libgst-0.3.2.so.0 > #3 0x408c6f62 in gst_filesrc_get_type () from /usr/lib/gst/libgstelements.so > > Then a few seconds later: > > Program received signal SIGINT, Interrupt. > 0x4060cd8a in g_tree_nnodes () from /usr/lib/libglib-1.3.so.15 > (gdb) where > #0 0x4060cd8a in g_tree_nnodes () from /usr/lib/libglib-1.3.so.15 > #1 0x4060c58f in g_tree_search () from /usr/lib/libglib-1.3.so.15 > #2 0x405fa595 in g_mem_chunk_alloc () from /usr/lib/libglib-1.3.so.15 > #3 0x40039a29 in gst_event_new () from /usr/lib/libgst-0.3.2.so.0 > #4 0x408c6f62 in gst_filesrc_get_type () from /usr/lib/gst/libgstelements.so > > Any suggestions? > > i noticed a brief comment in the release notes about events. It would > really be nice if there was a migration guide. i don't feel too bad > about API breakage if i know how to fix it. > > -- > Victory to the Divine Mother!! after all, > http://sahajayoga.org http://why-compete.org > > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > |
From: Joshua N P. <vi...@po...> - 2002-02-26 08:55:27
|
On Tue, Feb 26, 2002 at 09:39:49AM +0100, Benjamin Otte wrote: > Hm, I guess the reason nobody answers is that events are currently borked. Well, thanks for a straight answer. > We (wtay and me) were and are still thinking about a good and working way > to use events. > I am going to rewrite the event code nearly from scratch once I have the > time. So I would be very happy if I didn't need to debug that stuff. :) > > And the best suggestion I can give is "don't use it or rewrite it". > Sorry. i understand the need to more forward, but "seek to a byte offset" is critical to my application. It was working in 0.2.0 through 0.3.1. Someone broke it. Here are some ideas i might pursue within a few weeks: + Write a regression test for "seek to byte offset". + Verify that the seeking broke between 0.3.1 and 0.3.2. + Submit a patch to back-out whatever changes broke the seeking between 0.3.1 and 0.3.2. > I know somebody will flame me on IRC for being so negative, but oh well... Flames are irrelevant. i just want working code. -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org |
From: Joshua N P. <vi...@po...> - 2002-02-27 10:27:09
|
On Tue, Feb 26, 2002 at 02:25:17PM +0530, Joshua N Pritikin wrote: > i understand the need to more forward, but "seek to a byte offset" is > critical to my application. It was working in 0.2.0 through 0.3.1. > Someone broke it. Here are some ideas i might pursue within a few > weeks: > > + Verify that the seeking broke between 0.3.1 and 0.3.2. OK, i verified that my code works fine with the 0.3.1-3 debs. Something broke between 0.3.1 and 0.3.2. More info to follow ... -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org |
From: Ronald B. <rb...@ro...> - 2002-02-26 08:52:19
|
On Mon, 2002-02-25 at 16:16, Joshua N Pritikin wrote: > redael-filmview (pid:3503): GStreamer-ERROR **: file gstpad.c: > line 1502 (gst_real_pad_dispose): assertion failed: (GST_PAD_PEER > (pad) == NULL) Isn't this a bug? Why should the peer pad be NULL for an event to take place? Ronald -- - .-. - /V\ | Ronald Bultje <rb...@ro...> - // \\ | Running: Linux 2.4.17-XFS and OpenBSD 3.0 - /( )\ | http://ronald.bitfreak.net/ - ^^-^^ |
From: Joshua N P. <vi...@po...> - 2002-02-26 08:59:16
|
On Tue, Feb 26, 2002 at 09:52:14AM +0100, Ronald Bultje wrote: > On Mon, 2002-02-25 at 16:16, Joshua N Pritikin wrote: > > redael-filmview (pid:3503): GStreamer-ERROR **: file gstpad.c: > > line 1502 (gst_real_pad_dispose): assertion failed: (GST_PAD_PEER > > (pad) == NULL) > > Isn't this a bug? Why should the peer pad be NULL for an event to take > place? Or more importantly, why is submitting an event causing the source pad to get destroyed? It seems like a ref-counting problem. i tried g_object_ref on the pad, but then it gets stuck in g_tree_search in filesrc. See my original email for stack traces. -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org |
From: Joshua N P. <vi...@po...> - 2002-02-27 08:53:17
|
On Tue, Feb 26, 2002 at 08:33:39PM +0100, Wim Taymans wrote: > On Tue, 2002-02-26 at 09:59, Joshua N Pritikin wrote: > > Or more importantly, why is submitting an event causing the source pad > > to get destroyed? It seems like a ref-counting problem. i tried > > g_object_ref on the pad, but then it gets stuck in g_tree_search > > in filesrc. See my original email for stack traces. > > I suspect a refcounting problem too, when an event is fires, the first > pad that receives the event is refcounted and marked as the source for > the event. An unref occurs on gst_event_free. It gets a little hard to > keep refcounting consistent as events are not refcounted (to be > changed). > > Can you try to track this down? Sure, but before i dive into the code, can i run a few questions by you? * Is it a new "feature" that events are holding references to the pad? * Did you check the correctness of the event handling code in mpegdemux? (Each event is copied per sink pad and submitted downstream.) * Can you think of any unrelated, suspicious changes in filesrc which might cause problems? -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org |
From: Joshua N P. <vi...@po...> - 2002-03-01 07:10:33
|
On Wed, Feb 27, 2002 at 02:23:11PM +0530, Joshua N Pritikin wrote: > * Is it a new "feature" that events are holding references to the pad? No, 0.3.1 is the same. > * Did you check the correctness of the event handling code in mpegdemux? > (Each event is copied per sink pad and submitted downstream.) No change since 0.3.1. > * Can you think of any unrelated, suspicious changes in filesrc which > might cause problems? Again, the changes are insignificant. Hrm. -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org |
From: Joshua N P. <vi...@po...> - 2002-03-01 06:35:50
|
On Tue, Feb 26, 2002 at 08:33:39PM +0100, Wim Taymans wrote: > I suspect a refcounting problem too, when an event is fires, the first > pad that receives the event is refcounted and marked as the source for > the event. An unref occurs on gst_event_free. It gets a little hard to > keep refcounting consistent as events are not refcounted (to be > changed). > > Can you try to track this down? Actually i probably won't have time to debug this for a least the next 7 days. -- Victory to the Divine Mother!! after all, http://sahajayoga.org http://why-compete.org |