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

ROSH CHERIAN rosh at tid.es
Mon May 19 16:06:09 CEST 2008


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);
           printf("###########  Setting priority of '%s' running in thread %x to %d ######## \n",

           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.

- 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstobject.c
Type: text/x-csrc
Size: 35065 bytes
Desc: gstobject.c
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20080519/9a1c93f5/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstobject.h
Type: text/x-chdr
Size: 10118 bytes
Desc: gstobject.h
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20080519/9a1c93f5/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstpad.c
Type: text/x-csrc
Size: 127582 bytes
Desc: gstpad.c
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20080519/9a1c93f5/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gstpad.h
Type: text/x-chdr
Size: 32290 bytes
Desc: gstpad.h
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20080519/9a1c93f5/attachment-0001.h>

More information about the gstreamer-devel mailing list