Guidance requested on location of sensors header

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Guidance requested on location of sensors header

Martin Kelly
Hi,

Yesterday, ahssrc (Android hardware sensor source) was accepted into
gst-plugins-bad (https://bugzilla.gnome.org/show_bug.cgi?id=768110).

However, the plugin has a lingering issue, which is that ahssrc contains
a header with its caps and some structs for dealing with the associated
data. I would like this header to be usable both by apps and,
eventually, also other plugins dealing with sensor data (e.g. sensor
sinks). However, I'm not sure where that header should go and how to
construct the proper Makefile rules to make that happen. gst-libs seems
promising, but it seems like most or all of it is dedicated libraries,
whereas in this case I just want to publish a single header.

Could someone advise where I should install these headers, and what
Makefile rules to use?

Thanks,
Martin
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Guidance requested on location of sensors header

Martin Kelly
On 07/15/2016 11:26 AM, Martin Kelly wrote:

> Hi,
>
> Yesterday, ahssrc (Android hardware sensor source) was accepted into
> gst-plugins-bad (https://bugzilla.gnome.org/show_bug.cgi?id=768110).
>
> However, the plugin has a lingering issue, which is that ahssrc contains
> a header with its caps and some structs for dealing with the associated
> data. I would like this header to be usable both by apps and,
> eventually, also other plugins dealing with sensor data (e.g. sensor
> sinks). However, I'm not sure where that header should go and how to
> construct the proper Makefile rules to make that happen. gst-libs seems
> promising, but it seems like most or all of it is dedicated libraries,
> whereas in this case I just want to publish a single header.
>
> Could someone advise where I should install these headers, and what
> Makefile rules to use?
>
> Thanks,
> Martin

(friendly ping)
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Guidance requested on location of sensors header

Arun Raghavan-4


On Sun, 24 Jul 2016, at 12:04 AM, Martin Kelly wrote:

> On 07/15/2016 11:26 AM, Martin Kelly wrote:
> > Hi,
> >
> > Yesterday, ahssrc (Android hardware sensor source) was accepted into
> > gst-plugins-bad (https://bugzilla.gnome.org/show_bug.cgi?id=768110).
> >
> > However, the plugin has a lingering issue, which is that ahssrc contains
> > a header with its caps and some structs for dealing with the associated
> > data. I would like this header to be usable both by apps and,
> > eventually, also other plugins dealing with sensor data (e.g. sensor
> > sinks). However, I'm not sure where that header should go and how to
> > construct the proper Makefile rules to make that happen. gst-libs seems
> > promising, but it seems like most or all of it is dedicated libraries,
> > whereas in this case I just want to publish a single header.
> >
> > Could someone advise where I should install these headers, and what
> > Makefile rules to use?

Maybe it makes sense to pack the data in a GstStructure (which
encapsulates (key, type, value) tuples)?

-- Arun
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Guidance requested on location of sensors header

Martin Kelly
On 07/24/2016 09:37 PM, Arun Raghavan wrote:
> On Sun, 24 Jul 2016, at 12:04 AM, Martin Kelly wrote:
>
> Maybe it makes sense to pack the data in a GstStructure (which
> encapsulates (key, type, value) tuples)?
>
> -- Arun

For apps outside the pipeline, this could work. However, for plugins
(say, a sensorfilter of some kind), this is an inconvenient/inefficient
format. It seems to me that it's best to leave it as a GstBuffer by
default, with possibly a method for converting to a GstStructure, if
apps find that useful (I'm not sure if they would).
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel