[Tuesday 04 Feb 2014] [15:43:02] <wtay> capOM, placing an indication in the allocation query that a thread boundary is to be crossed sounds like a good idea
[Tuesday 04 Feb 2014] [15:43:24] <wtay> capOM, I don't think you should have the thread-id there, it can change with every buffer push
[Tuesday 04 Feb 2014] [15:45:17] <capOM>  wtay: it's mainly in to use in "decide_allocation", so that you know if the "propose_allocation" call was made in a different streaming thread
[Tuesday 04 Feb 2014] [15:46:33] <wtay> capOM, those are methods on the same element, no? so the element knows if it makes a thread or not
[Tuesday 04 Feb 2014] [15:49:18] <capOM>  wtay:   elementA ! elementB    , A does the allocation query, B does  "propose_allocation",  A does  "decide_allocation".   With the new API in the 2 first patch you can know in A if there is a queue between A and B.
[Tuesday 04 Feb 2014] [15:49:57] <capOM>  could be a queue or more complex stuff that introduce a different streaming thread
[Tuesday 04 Feb 2014] [15:50:33] <capOM>  Third patch is a unit test
[Tuesday 04 Feb 2014] [15:54:10] <wtay> capOM, because of serialized queries..
[Tuesday 04 Feb 2014] [15:54:34] <capOM>  wtay: yes it's a patch only for serialized queries
[Tuesday 04 Feb 2014] [15:54:59] <capOM>  wtay: I mentioned it in the doc :)
[Tuesday 04 Feb 2014] [15:55:09] <wtay> capOM, yes
[Tuesday 04 Feb 2014] [15:56:07] <wtay> capOM, you only need to know if there is thread boundary, not exactly the thread id, right?
[Tuesday 04 Feb 2014] [15:56:22] <capOM>  wtay: yes exactly
[Tuesday 04 Feb 2014] [15:57:09] <wtay> capOM, it sounds useful then to add to the allocation query that producer and consumer might be running in different threads
[Tuesday 04 Feb 2014] [15:58:39] <capOM>  wtay: for my specific case I actually do not need the information that tells how many threads exactly ( n_streaming_threads ),  but I thought it could be useful too
[Tuesday 04 Feb 2014] [15:59:17] <capOM>  wtay: I mean in my case I just test  "gst_query_get_n_streaming_threads > 1"
[Tuesday 04 Feb 2014] [16:00:19] <wtay> capOM, I would not rely on it, one dynamically added queue and it's already wrong
[Tuesday 04 Feb 2014] [16:00:42] <slomo_> wtay: but you get a reconfigure event then
[Tuesday 04 Feb 2014] [16:01:02] <wtay> slomo_, yes
