[gst-devel] How do I get gst-inspect properties for v4l2src device other than /dev/video0?

[Short, Jonathan]

> -----Original Message-----
> From: Stefan Kost [mailto:ensonic at hora-obscura.de]
> Sent: Tuesday, April 20, 2010 2:47 PM
> To: Discussion of the development of GStreamer
> Cc: Short, Jonathan
> Subject: Re: [gst-devel] How do I get gst-inspect properties for
> v4l2src device other than /dev/video0?
> 
> Am 19.04.2010 19:20, schrieb Short, Jonathan:
> >
> >> -----Original Message-----
> >> From: Edward Hervey [mailto:bilboed at gmail.com]
> >> Sent: Saturday, April 17, 2010 12:15 PM
> >> To: Discussion of the development of GStreamer
> >> Subject: Re: [gst-devel] How do I get gst-inspect properties for
> >> v4l2src device other than /dev/video0?
> >>
> >> On Fri, 2010-04-16 at 14:53 -0500, Kulecz, Walter (JSC-SK)[WYLE
> INTEG.
> >> SCI. & ENG.] wrote:
> >>>> Camera sources are live-sources. That means
> >> GST_BUFFER_TIMESTAMP(buf) is
> >>>> a clock sample of the time when the frame was captured
> >>>> (clocktime-basetime). Thats why it is a good idea to use
operating
> >>>> system mechanisms to run those capture threads at higher priority
> >> or
> >>>> even under realtime scheduling (avoiding jitter in the
> > timestamps).
> >>>>
> >>>> Stefan
> >
> > Is there a preferred method for setting the thread priorities of
> > sources, given that different sources may have different internal
> > threading structure and threading is generally abstracted by
> gstreamer?
> >
> > For example, I'd like to set the priority of rtspsrc as suggested
> above.
> 
> Have a look at the examples under gstreamer/tests/examples/streams/.
It
> is
> unfortunately platform specific. Glibs gthread abstraction does not
> cover this
> area (well).
> 
> Stefan


Thanks greatly for the info.  I had a look at the examples, and can see
how to set thread priority now.  The one part I'm not clear on is how to
ensure that I am only setting the priority of the capture thread and not
others.  For instance, our pipeline has quite a few queues in it.  Its
not clear to me from the examples how the rtspsrc thread would be set at
a high priority while the consumer threads further down the pipeline
wouldn't.  Also based on the thread pool nature of gstreamer, is there
any assurance that the higher priority thread won't later be used for
something else?

Thanks again,

Jonathan