[Bug 791601] new element: gpsdsrc

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from Martin Kelly <mkelly at xevo.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #4)
> (In reply to Tim-Philipp Müller from comment #3)
> > What is the actual / eventual purpose of this element, if I may ask?
> 
> Real-Time stream geolocalisation seems very useful to me. Combine this with
> color video, depth stream and gyroscopic data, you could turn a video
> recording into 3D.

Yes, this is a great use case, and there are many others. Others include
geofencing such that you start recording video/audio when you reach a certain
longitude/latitude region, or multiplexing GPS data along with A/V data into a
single mp4 file containing everything correlated on a per-frame basis. This
also
can be used to easily send GPS data over a network. And, at its most basic, it
can be a one-liner to sample from the GPS in real-time.

Of course, to fully flesh out these use cases, we'd need a few more elements:

- gpsdenc: transform from in-memory gps_fix_t format to a persistent,
  machine-independent format. This would be used prior to sending off the
  machine or saving to a file.
- gpsddec: transform from a persistent, machine-independent format back into
  in-memory gps_fix_t format.
- gpsconvert: convert from gps_fix_t format to something human-readable, like
  text or JSON. Then GPS data could be displayed by a text sink, over sent over
  the network to a non-gstreamer application.

I would like to do these in the future, or someone else could, but we need to
start with a source to acquire the data.

> > 
> > What would seem more generally useful to me is for example an element that
> > puts current GPS co-ordinates as metadata on buffers, for example.
> 
> Though that needs to happen in two steps, since you need to first synch the
> GPS fixes with the data because of the delays. You cannot request a fix in
> the past, you need to capture, synch and then you can merge or mux.
> 

Yes. I think that treating GPS and other sensors as first-class citizens with
buffers dedicated to them will help in multiplexing and syncing up with A/V
data. In addition, it allows all the above use cases that might not even use
A/V
data but be interesting in their own right.

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