[gst-devel] A Proposal for Real Time "priority" property in Gstreamer framework
Mattias Barthel
mb at novanotio.es
Mon May 19 20:35:52 CEST 2008
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(¶m, 0, sizeof(sched_param));
param.sched_priority = prio;
if(sched_setscheduler(0, SCHED_FIFO, ¶m) == -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(¶m, 0, sizeof(sched_param));
>> param.sched_priority = objPar->_prio;
>> if(sched_setscheduler(0, SCHED_FIFO, ¶m) == -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
>
>
>
More information about the gstreamer-devel
mailing list