[Bug 768110] New: new plugin: ahssrc (Android hardware sensor source)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=768110

            Bug ID: 768110
           Summary: new plugin: ahssrc (Android hardware sensor source)
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: martin at surround.io
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 330460
  --> https://bugzilla.gnome.org/attachment.cgi?id=330460&action=edit
new plugin: Android hardware sensor source

ahssrc is a new plugin that enables Gstreamer to read from the
android.hardware.sensor Android sensors. These sensors are treated as buffers
and can be passed through and manipulated by the pipeline.

To my knowledge, this is the first GStreamer plugin that handles analog sensor
data. Treating sensors as buffers in the pipeline is useful because sensor data
fits naturally as a data stream, and it can be very high rate, requiring high
performance (e.g. accelerometers can generate over 1000Hz). If sensors are just
another data type, then they can be multiplexed alongside audio and video,
allowing per-frame correlation. For example, you could have a video frame with
corresponding accelerometer, gyroscope, barometer, and light level
measurements, enabling very precise correlation of multiple data types
together. In addition, sensors as streams can be throttled, buffered, and
aggregated, just as you might with video or audio.

I would like some feedback regarding a few aspects of the implementation:

- My current buffer format is just binary, mapping to some simple structs that
correspond to the equivalent types in the android.hardware.Sensor API. I intend
the structs to be in an exported header file. Although this works well for
Android sensor data, it's possible that this won't map well to non-Android
sensors, if other platforms expose a slightly different schema for their data.
However, without knowing the universe of possibilities, I figured that starting
with the Android API was reasonable. What do you think?

- Currently, the file gstahscaps.h is not exported anywhere, but it should be
exported so that other plugins can handle the sensor data coming from ahssrc.
Ideally, this should be exported somewhere that is not Android-specific (e.g.
not in androidmedia), as sensor data should be able to be generated and handled
by non-Android platforms too. What is the best way to accomplish this?

Thanks!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.