After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703267 - funnel: Needs to be usable in playbin
funnel: Needs to be usable in playbin
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: 1.1.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-06-28 15:47 UTC by Brendan Long
Modified: 2013-07-10 15:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Python script that runs playbin with a funnel as the text-stream-combiner (1.34 KB, text/plain)
2013-07-01 17:44 UTC, Brendan Long
  Details
Only send one stream-start event in funnel (1.94 KB, patch)
2013-07-01 22:12 UTC, Brendan Long
rejected Details | Review

Description Brendan Long 2013-06-28 15:47:40 UTC
For WebKit, we need an element that can be used as the text-stream-combiner in playbin. It needs to:

  * Combine multiple text streams into one.
  * The pads need to:
      * Allow us to activate and deactivate streams.
      * Expose tags.

Adder is similar to what we need, but it waits until it gets buffers on all of the pads, and that could cause problems in text streams, since we may not have buffers on every pad. We also don't want to merge the buffers, we just want to forward all of them.

I'm starting on an element I'm calling "textmixer" for now (I'm open to better names, maybe "bufferforwarder" or "rawstreamcombiner" or something), but I wanted to make sure I'm not missing an obvious easier way to handle this.
Comment 1 Tim-Philipp Müller 2013-06-28 15:49:06 UTC
> I'm starting on an element I'm calling "textmixer" for now (I'm open to better
> names, maybe "bufferforwarder" or "rawstreamcombiner" or something), but I
> wanted to make sure I'm not missing an obvious easier way to handle this.

That sounds like 'funnel' ?
Comment 2 Brendan Long 2013-06-28 15:53:59 UTC
(In reply to comment #1)
> That sounds like 'funnel' ?

That looks right. I may need to add some things to it though (tags, ability to enable and disable, a way to tell what pad a buffer is from), but that will be much easier to start with.
Comment 3 Brendan Long 2013-06-28 22:43:04 UTC
funnel doesn't seem to work correctly in playbin:

gst-git gst-launch-1.0 playbin uri=http://ftp.nluug.nl/ftp/graphics/blender/apricot/trailer/Sintel_Trailer1.480p.DivX_Plus_HD.mkv text-stream-combiner="funnel"
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Redistribute latency...
buffering... 100%
# hang
Comment 4 Olivier Crête 2013-06-29 00:43:40 UTC
To enable/disable a stream, can't you just put a valve before each branch of the funnel?

For the tags, I think we should keep track of the pad that is pushing a buffer, and if it's not the same as the last one, push all of the sticky events (and not push them otherwise).

While we're at it, I'm not sure if the segment handling in funnel is still required ?
Comment 5 Sebastian Dröge (slomo) 2013-06-30 12:47:36 UTC
And the information about which pad a buffer comes from could be added as a new GstMeta on the buffers.

segment handling in funnel should not be needed anymore, however it would need to forward all sticky events of the current input pad before each buffer after a input pad switch.
Comment 6 Brendan Long 2013-07-01 17:44:41 UTC
Created attachment 248170 [details]
Python script that runs playbin with a funnel as the text-stream-combiner

The problems with playbin are because the stream-combiners can't be bins: https://bugzilla.gnome.org/show_bug.cgi?id=703405

I'm using a Python script to test this now (attached). It doesn't stall the pipeline, but I also don't see any subtitles. Run like:

    gst-git ./playbin-funnel.py http://ftp.nluug.nl/ftp/graphics/blender/apricot/trailer/Sintel_Trailer1.480p.DivX_Plus_HD.mkv  --use-funnel
Comment 7 Brendan Long 2013-07-01 18:07:58 UTC
It looks like the funnel (thread 9) can't push its buffers because the stream lock is held by something in thread 10, which is waiting on stream synchronizer to get some event related to the segment.

Thread 16 (Thread 0x7fffbe7fc700 (LWP 12403))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 gst_pad_chain_data_unchecked
    at gstpad.c line 3671
  • #4 gst_pad_push_data
    at gstpad.c line 3948
  • #5 gst_pad_push
    at gstpad.c line 4051
  • #6 gst_funnel_sink_chain
    at gstfunnel.c line 322
  • #7 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #8 gst_pad_push_data
    at gstpad.c line 3948
  • #9 gst_pad_push
    at gstpad.c line 4051
  • #10 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #11 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #12 gst_pad_push_data
    at gstpad.c line 3948
  • #13 gst_pad_push
    at gstpad.c line 4051
  • #14 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #15 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #16 gst_pad_push_data
    at gstpad.c line 3948
  • #17 gst_pad_push
    at gstpad.c line 4051
  • #18 gst_single_queue_push_one
    at gstmultiqueue.c line 1059
  • #19 gst_multi_queue_loop
    at gstmultiqueue.c line 1307
  • #20 gst_task_func
    at gsttask.c line 316
  • #21 default_func
    at gsttaskpool.c line 70
  • #22 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #23 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #24 start_thread
    at pthread_create.c line 308
  • #25 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #26 ??

Thread 15 (Thread 0x7fffbeffd700 (LWP 12402))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 gst_pad_chain_data_unchecked
    at gstpad.c line 3671
  • #4 gst_pad_push_data
    at gstpad.c line 3948
  • #5 gst_pad_push
    at gstpad.c line 4051
  • #6 gst_funnel_sink_chain
    at gstfunnel.c line 322
  • #7 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #8 gst_pad_push_data
    at gstpad.c line 3948
  • #9 gst_pad_push
    at gstpad.c line 4051
  • #10 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #11 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #12 gst_pad_push_data
    at gstpad.c line 3948
  • #13 gst_pad_push
    at gstpad.c line 4051
  • #14 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #15 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #16 gst_pad_push_data
    at gstpad.c line 3948
  • #17 gst_pad_push
    at gstpad.c line 4051
  • #18 gst_single_queue_push_one
    at gstmultiqueue.c line 1059
  • #19 gst_multi_queue_loop
    at gstmultiqueue.c line 1307
  • #20 gst_task_func
    at gsttask.c line 316
  • #21 default_func
    at gsttaskpool.c line 70
  • #22 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #23 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #24 start_thread
    at pthread_create.c line 308
  • #25 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #26 ??

Thread 14 (Thread 0x7fffbf7fe700 (LWP 12401))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 gst_pad_chain_data_unchecked
    at gstpad.c line 3671
  • #4 gst_pad_push_data
    at gstpad.c line 3948
  • #5 gst_pad_push
    at gstpad.c line 4051
  • #6 gst_funnel_sink_chain
    at gstfunnel.c line 322
  • #7 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #8 gst_pad_push_data
    at gstpad.c line 3948
  • #9 gst_pad_push
    at gstpad.c line 4051
  • #10 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #11 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #12 gst_pad_push_data
    at gstpad.c line 3948
  • #13 gst_pad_push
    at gstpad.c line 4051
  • #14 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #15 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #16 gst_pad_push_data
    at gstpad.c line 3948
  • #17 gst_pad_push
    at gstpad.c line 4051
  • #18 gst_single_queue_push_one
    at gstmultiqueue.c line 1059
  • #19 gst_multi_queue_loop
    at gstmultiqueue.c line 1307
  • #20 gst_task_func
    at gsttask.c line 316
  • #21 default_func
    at gsttaskpool.c line 70
  • #22 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #23 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #24 start_thread
    at pthread_create.c line 308
  • #25 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #26 ??

Thread 13 (Thread 0x7fffbffff700 (LWP 12400))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 gst_pad_chain_data_unchecked
    at gstpad.c line 3671
  • #4 gst_pad_push_data
    at gstpad.c line 3948
  • #5 gst_pad_push
    at gstpad.c line 4051
  • #6 gst_funnel_sink_chain
    at gstfunnel.c line 322
  • #7 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #8 gst_pad_push_data
    at gstpad.c line 3948
  • #9 gst_pad_push
    at gstpad.c line 4051
  • #10 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #11 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #12 gst_pad_push_data
    at gstpad.c line 3948
  • #13 gst_pad_push
    at gstpad.c line 4051
  • #14 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #15 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #16 gst_pad_push_data
    at gstpad.c line 3948
  • #17 gst_pad_push
    at gstpad.c line 4051
  • #18 gst_single_queue_push_one
    at gstmultiqueue.c line 1059
  • #19 gst_multi_queue_loop
    at gstmultiqueue.c line 1307
  • #20 gst_task_func
    at gsttask.c line 316
  • #21 default_func
    at gsttaskpool.c line 70
  • #22 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #23 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #24 start_thread
    at pthread_create.c line 308
  • #25 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #26 ??

Thread 12 (Thread 0x7fffe0abc700 (LWP 12399))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 gst_pad_chain_data_unchecked
    at gstpad.c line 3671
  • #4 gst_pad_push_data
    at gstpad.c line 3948
  • #5 gst_pad_push
    at gstpad.c line 4051
  • #6 gst_funnel_sink_chain
    at gstfunnel.c line 322
  • #7 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #8 gst_pad_push_data
    at gstpad.c line 3948
  • #9 gst_pad_push
    at gstpad.c line 4051
  • #10 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #11 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #12 gst_pad_push_data
    at gstpad.c line 3948
  • #13 gst_pad_push
    at gstpad.c line 4051
  • #14 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #15 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #16 gst_pad_push_data
    at gstpad.c line 3948
  • #17 gst_pad_push
    at gstpad.c line 4051
  • #18 gst_single_queue_push_one
    at gstmultiqueue.c line 1059
  • #19 gst_multi_queue_loop
    at gstmultiqueue.c line 1307
  • #20 gst_task_func
    at gsttask.c line 316
  • #21 default_func
    at gsttaskpool.c line 70
  • #22 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #23 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #24 start_thread
    at pthread_create.c line 308
  • #25 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #26 ??

Thread 11 (Thread 0x7fffe12bd700 (LWP 12398))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 gst_pad_chain_data_unchecked
    at gstpad.c line 3671
  • #4 gst_pad_push_data
    at gstpad.c line 3948
  • #5 gst_pad_push
    at gstpad.c line 4051
  • #6 gst_funnel_sink_chain
    at gstfunnel.c line 322
  • #7 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #8 gst_pad_push_data
    at gstpad.c line 3948
  • #9 gst_pad_push
    at gstpad.c line 4051
  • #10 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #11 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #12 gst_pad_push_data
    at gstpad.c line 3948
  • #13 gst_pad_push
    at gstpad.c line 4051
  • #14 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #15 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #16 gst_pad_push_data
    at gstpad.c line 3948
  • #17 gst_pad_push
    at gstpad.c line 4051
  • #18 gst_single_queue_push_one
    at gstmultiqueue.c line 1059
  • #19 gst_multi_queue_loop
    at gstmultiqueue.c line 1307
  • #20 gst_task_func
    at gsttask.c line 316
  • #21 default_func
    at gsttaskpool.c line 70
  • #22 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #23 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #24 start_thread
    at pthread_create.c line 308
  • #25 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #26 ??

Thread 9 (Thread 0x7fffe22bf700 (LWP 12396))

  • #0 __lll_lock_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S line 132
  • #1 _L_lock_903
    from /lib/x86_64-linux-gnu/libpthread.so.0
  • #2 __pthread_mutex_lock
    at pthread_mutex_lock.c line 82
  • #3 gst_pad_chain_data_unchecked
    at gstpad.c line 3671
  • #4 gst_pad_push_data
    at gstpad.c line 3948
  • #5 gst_pad_push
    at gstpad.c line 4051
  • #6 gst_funnel_sink_chain
    at gstfunnel.c line 322
  • #7 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #8 gst_pad_push_data
    at gstpad.c line 3948
  • #9 gst_pad_push
    at gstpad.c line 4051
  • #10 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #11 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #12 gst_pad_push_data
    at gstpad.c line 3948
  • #13 gst_pad_push
    at gstpad.c line 4051
  • #14 gst_proxy_pad_chain_default
    at gstghostpad.c line 128
  • #15 gst_pad_chain_data_unchecked
    at gstpad.c line 3718
  • #16 gst_pad_push_data
    at gstpad.c line 3948
  • #17 gst_pad_push
    at gstpad.c line 4051
  • #18 gst_single_queue_push_one
    at gstmultiqueue.c line 1059
  • #19 gst_multi_queue_loop
    at gstmultiqueue.c line 1307
  • #20 gst_task_func
    at gsttask.c line 316
  • #21 default_func
    at gsttaskpool.c line 70
  • #22 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #23 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #24 start_thread
    at pthread_create.c line 308
  • #25 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #26 ??

Comment 8 Brendan Long 2013-07-01 21:03:16 UTC
(In reply to comment #7)
The lockup seems to be because of this code in `gst_stream_synchronizer_sink_event`:

      if (stream) {
        if (stream->wait) {
          GST_DEBUG_OBJECT (pad, "Stream %d is waiting", stream->stream_number);
          g_cond_wait (&stream->stream_finish_cond, &self->lock);
          stream = gst_pad_get_element_private (pad);
          if (stream)
            stream->wait = FALSE;
        }
      }

If I comment it out, the funnel works. I'm not sure why the stream is waiting though. It looks like if the stream changes, it waits, but for some reason it doesn't stop waiting.

If I change a couple relevant log messages to INFO, I get:

0:00:00.174538788  4031 0x7f9a58013990 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_0> Stream 0 changed
0:00:00.174584992  4031 0x7f9a5802e2d0 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.174619845  4031 0x7f9a600b4140 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_1> Stream 1 changed
0:00:00.174649543  4031 0x7f9a600b4140 INFO      streamsynchronizer gststreamsynchronizer.c:291:gst_stream_synchronizer_sink_event:<streamsynchronizer0> All streams have changed -- unblocking
0:00:00.174710411  4031 0x7f9a5802e2d0 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.174780529  4031 0x7f9a58039140 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.174823157  4031 0x7f9a5802e630 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.175018287  4031 0x7f9a5802e1e0 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.175082229  4031 0x7f9a58039370 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.175137989  4031 0x7f9a5802e0a0 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.175322636  4031 0x7f9a580390a0 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.175366048  4031 0x7f9a58039320 INFO      streamsynchronizer gststreamsynchronizer.c:276:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 changed
0:00:00.206073080  4031 0x7f9a5802e2d0 INFO      streamsynchronizer gststreamsynchronizer.c:341:gst_stream_synchronizer_sink_event:<streamsynchronizer0:sink_2> Stream 2 is waiting
Comment 9 Brendan Long 2013-07-01 21:08:34 UTC
I guess the problem is that the funnel is forwarding all of the stream events instead of creating a new stream?
Comment 10 Brendan Long 2013-07-01 22:12:57 UTC
Created attachment 248188 [details] [review]
Only send one stream-start event in funnel

I'm not sure if we want to change funnel to only send one stream-start event, or change stream synchronizer to not wait forever if we get multiple streams on one pad. This patch does the funnel change.
Comment 11 Brendan Long 2013-07-01 22:22:08 UTC
(In reply to comment #10)
> Created an attachment (id=248188) [details] [review]
> Only send one stream-start event in funnel

Sometimes this causes "Sticky event misordering, got 'caps' before 'stream-start'" :\ I guess I could use a lock/condition on caps..
Comment 12 Brendan Long 2013-07-01 22:44:36 UTC
(In reply to comment #11)
> Sometimes this causes "Sticky event misordering, got 'caps' before
> 'stream-start'" :\ I guess I could use a lock/condition on caps..

And if I add a lock/condition so caps get sent after the stream start event, I get warnings about "Got data flow before segment event". I'm guessing we don't want a bunch of locks to keep data in order. I guess we could probably gobble all of the sticky events, and only send them right before data.
Comment 13 Brendan Long 2013-07-01 23:01:44 UTC
I'm looking at the GstMeta now, but I'm not exactly sure how it's supposed to be used. Do I define a GstMeta subclass in gstfunnel.c, or does it go somewhere else so other elements can use this? Are there examples somewhere of this being used?
Comment 14 Olivier Crête 2013-07-02 01:26:06 UTC
Finally really ported funnel to 1.x, about a year late. I removed the event specific code for all events except EOS (which have to be accumulated).

As for the multiple stream-start problem, I'm blaming streamsynchronizer.

commit 176e16aa5ffaa8a357873970aa420f56fff72be0
Author: Olivier Crête <olivier.crete@collabora.com>
Date:   Mon Jul 1 20:21:10 2013 -0400

    funnel: Use default pad function for upstream event/queries
    
    The default functions in 1.x already do the right thing

commit bbb26f875692a6cd84050c545ba85a7d2129cf5d
Author: Olivier Crête <olivier.crete@collabora.com>
Date:   Mon Jul 1 20:35:21 2013 -0400

    funnel: Re-push all sticky events when buffers come from a different pad
    
    Don't special case segment/caps, just push all sticky events when they are
    received on the currently active pad or when the active pad changes.
Comment 15 Olivier Crête 2013-07-02 01:30:47 UTC
I guess to make stream-synchronizer happy, the demuxers should put the same seqnum on all stream-starts event it sends for a specific file?
Comment 16 Sebastian Dröge (slomo) 2013-07-02 07:14:18 UTC
(In reply to comment #15)
> I guess to make stream-synchronizer happy, the demuxers should put the same
> seqnum on all stream-starts event it sends for a specific file?

Well, not necessarily? streamsynchronizer only requires the same seqnum for a single stream, e.g. an audio and video stream of the same container file can have different seqnums... and also different stream-ids.

However I see the problem here with funnel, it will forward the different stream-start events of all input streams and confuse streamsynchronizer with that. Maybe funnel should only create a single stream-start event, and in there have a stream-id that is a combination of all input stream-ids?

Or maybe the logic in streamsynchronizer needs to be changed, it's the cause of problems since quite some time. Maybe all this has to be implemented differently
Comment 17 Sebastian Dröge (slomo) 2013-07-02 07:18:36 UTC
(In reply to comment #13)
> I'm looking at the GstMeta now, but I'm not exactly sure how it's supposed to
> be used. Do I define a GstMeta subclass in gstfunnel.c, or does it go somewhere
> else so other elements can use this? Are there examples somewhere of this being
> used?

You would have to put the GstMeta in a public library somewhere, otherwise the definiton of the meta wouldn't be available to code outside gstfunnel unfortunately. If that wouldn't be a problem you could as well define it inside gstfunnel.c.

But as this meta is very funnel specific I wouldn't know in which library to put it. Maybe instead of doing that you could do something with the stream-start events that are now sent between each switch of inputs? Or funnel could introduce a new, custom sticky event for that?
Comment 18 Brendan Long 2013-07-03 18:15:38 UTC
(In reply to comment #17)
> Maybe instead of doing that you could do something with the
> stream-start events that are now sent between each switch of inputs? Or funnel
> could introduce a new, custom sticky event for that?

The stream start events seem to be working, but I'm a little concerned that if I get a bunch of buffers at once, the stream start event will only be for the last one. If I handle the new samples in the callback for "new-sample", am I guaranteed to get to them before the next events are handled?
Comment 19 Brendan Long 2013-07-03 21:30:27 UTC
I guess I forgot to mention: For some reason funnel works with stream synchronizer now. I guess something in Olivier's changes fixed it for some reason.
Comment 20 Sebastian Dröge (slomo) 2013-07-04 08:10:17 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > Maybe instead of doing that you could do something with the
> > stream-start events that are now sent between each switch of inputs? Or funnel
> > could introduce a new, custom sticky event for that?
> 
> The stream start events seem to be working, but I'm a little concerned that if
> I get a bunch of buffers at once, the stream start event will only be for the
> last one. If I handle the new samples in the callback for "new-sample", am I
> guaranteed to get to them before the next events are handled?

A stream-start event will always arrive in front of the buffers to which it applies, so there should be no problem there.


(In reply to comment #19)
> I guess I forgot to mention: For some reason funnel works with stream
> synchronizer now. I guess something in Olivier's changes fixed it for some
> reason.

Means we can close this bug now? :)
Comment 21 Brendan Long 2013-07-05 14:39:37 UTC
(In reply to comment #20)
> A stream-start event will always arrive in front of the buffers to which it
> applies, so there should be no problem there.

I mean, if I have two samples, and I use gst_element_get_sticky_event(), I'll get the stream start event for the second sample twice. That's what was happening in WebKit when I waited for the g_timeout to finish, but now that I changed it to immediately handle the new sample in the "new-sample" callback, it seems to work.

What I'm wondering is if I'm just getting lucky (always handling it fast enough), or if it's guaranteed that I won't get another sample while I'm in that callback?
Comment 22 Olivier Crête 2013-07-05 15:17:20 UTC
Maybe sticky events should be attached to the GstSample structures, getting them from the element is clearly racy ?
Comment 23 Brendan Long 2013-07-05 20:51:38 UTC
(In reply to comment #22)
> Maybe sticky events should be attached to the GstSample structures, getting
> them from the element is clearly racy ?

I'm not sure if it would help, since the sample is created in `gst_app_sink_pull_sample`..
Comment 24 Brendan Long 2013-07-05 21:05:14 UTC
AppSink has its own special callbacks that seem to run immediately:

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-appsink.html#gst-app-sink-set-callbacks

I'm just wonder if emitting an event does the same thing?
Comment 25 Sebastian Dröge (slomo) 2013-07-08 13:10:17 UTC
(In reply to comment #22)
> Maybe sticky events should be attached to the GstSample structures, getting
> them from the element is clearly racy ?

Makes sense, for the segment and caps it already does that... so why not for all the other "context". Obviously getting the events from outside the stream is racy, you can only do the buffer-events relation from inside the stream.



(In reply to comment #24)
> AppSink has its own special callbacks that seem to run immediately:
> 
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-base-libs/html/gst-plugins-base-libs-appsink.html#gst-app-sink-set-callbacks
> 
> I'm just wonder if emitting an event does the same thing?

The callbacks are equivalent to the signals, just cause less overhead.
Comment 26 Brendan Long 2013-07-10 15:22:20 UTC
Olivier's commits fixed this, I'll open a new bug if the stream start events don't work.