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

Wim Taymans wim.taymans at gmail.com
Mon May 19 17:01:01 CEST 2008


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





More information about the gstreamer-devel mailing list