GStreamer-devel

A Proposal for Real Time "priority" property in Gstreamer framework

Classic

List

Threaded

4 messages Options

ROSH CHERIAN

A Proposal for Real Time "priority" property in Gstreamer framework

Hi,

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

gstobject.c (35K) Download Attachment

gstobject.h (10K) Download Attachment

gstpad.c (129K) Download Attachment

gstpad.h (32K) Download Attachment

Wim Taymans

Re: A Proposal for Real Time "priority" property in Gstreamer framework

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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Mattias Barthel

Re: A Proposal for Real Time "priority" property in Gstreamer framework

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 [hidden email] 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
>

Stefan Sauer

Re: A Proposal for Real Time "priority" property in Gstreamer framework

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 [hidden email] 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
>> [hidden email]
>> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel