[gst-devel] A Proposal for Real Time "priority" property in Gstreamer framework

[Stefan Kost]

Hi,

Mattias Barthel schrieb:
> Hi,
> 
> As a suggestion, there could be added to the g_thread library something 
> like g_thread_set_prio(int prio)
> and then depending of implementation, the corresponding calls would be 
> used;
> 
> #ifdef _HAVE_PTHREADS
> struct sched_param param;
> memset(&param, 0, sizeof(sched_param));
> param.sched_priority = prio;
> 
> if(sched_setscheduler(0, SCHED_FIFO, &param) == -1)  {
>  printf("error in setting priority >>>>>>>>>>> \n");
> }
> #elif _HAVE_GNU_PTH
> ....
> #endif
 >
No need for that. The docs for g_thread_set_priority() are simply not 
up-to-date. Its implemented for win32 and posix (and there only if 
HAVE_PRIORITIES is defined, but most systems actualy have it).

Downside of the gthread api clearly is the low priority resolution 
(GThreadPriority has only low, normal, high and urgent).

Stefan

> 
> 
> Mattias
> 
> 
> 
> Wim Taymans wrote:
>> On Mon, 2008-05-19 at 16:06 +0200, ROSH CHERIAN wrote:
>>   
>>> Hi,
>>>     
>> Hello,
>>
>> Yes, support for that is desirable. The idea is to be able to control
>> the priority of all streaming threads when they are created. The easiest
>> way to accomplish this to to implement and intercept the STREAM_STATUS
>> messages (they could contain the thread id, element that created them,
>> etc..) from there on the priority of those threads can be configured by
>> the application. 
>>
>> The current problem is that GThread does not seem to have a portable way
>> to configure thread priorities.
>>
>> Wim
>>  
>>
>>   
>>> Since the support for Real-Time has been getting better and better in linux, I propose that gstreamer should take advantage of this.
>>> This would help pipelines with elements having time-critical or heavy load where there is a demand for guaranteed cpu access.
>>> This could be achieved by giving higher scheduling priority to such plugins over others.
>>>
>>> Hence, my proposal is to have a property called "priority" for all elements.  Then, pipelines like the following one could be launched:
>>>
>>>      gst-launch   videotestsrc !   ffmpegcolorspace prio=90  ! xvimagesink
>>>
>>> Here, the thread containing ffmpegcolorspace's buffer processing method will get a higher priority than the rest.
>>>
>>> Another example would be a camera capture plugin, where there is a demand to capture frames with high accuracy.
>>>
>>> A layered priority is also possible, as below.
>>>      gst-launch   cameracapture prio=90 !   queue !  ffmpegcolorspace prio=50   ! queue !   ffenc_h264 prio=50 ! ...
>>>
>>>
>>> Implementation (I am sure there could be better ways, but this is what I tried):
>>> ----------------------------------------------------------------------------------------------------------------
>>> The files modified are enclosed.
>>>
>>>    1. I installed a new property called prio in gst-object.c, after the usual "name" property, in the method gst_object_class_init
>>>        Also, added a new field called _prio in gstobject class.
>>>        now all elements have prio property.
>>>
>>>
>>>     2. In gstpads.c, method gst_pad_push_event (GstPad * pad, GstEvent * event) method of gstpads.c,
>>>
>>>         GstObject* objPar =  (GstObject*) GST_OBJECT_PARENT (pad);
>>>         if(objPar->_prio!=0){
>>>            printf("###########  Setting priority of '%s' running in thread %x to %d ######## \n",
>>>            objPar->name,
>>>            pthread_self(),
>>>            objPar->_prio);
>>>
>>>            struct sched_param param;
>>>            memset(&param, 0, sizeof(sched_param));
>>>            param.sched_priority = objPar->_prio;
>>>            if(sched_setscheduler(0, SCHED_FIFO, &param) == -1)  {
>>>              printf("error in setting priority >>>>>>>>>>> \n");
>>>            }
>>>        }
>>>
>>>         This applies priorities to the threads where the element's processing function runs.
>>>
>>>
>>> Questions
>>> ---------------
>>> - Is such a mechanism of different priorities useful ?
>>>   I am testing some pipelines on machines that have high loads, and see good improvement in the overall speed of the pipeline, compared to no priority case.
>>>   However, it needs to be seen if it introduces additional complexity. Has anybody tested something like this? Please give some suggestions.
>>>
>>>
>>> Rosh Cherian
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft 
>>> Defy all challenges. Microsoft(R) Visual Studio 2008. 
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________ gstreamer-devel mailing list gstreamer-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>     
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft 
>> Defy all challenges. Microsoft(R) Visual Studio 2008. 
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>>
>>   
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel