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

[Mattias Barthel]

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


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
>
>
>