In Linux V4L2 and media controller architecture, we treat media devices as media entities and establish connections between them dynamically on the go..!! For example, demux0(demuxer 0) can be connected to Vid_plane1(Entity name given to the main video output). Also One media entity can be connected with multiple media entities at a time.
My question is if i want to find out how many enabled connections are existing from a particular media entities output pad(Sink pad), what is the method to find it?
You can use media-ctl utility, which will enumerate all v4l2 entities in specified media controller.
One thing you should pay attention to is the difference between target kernel version of media/v4l2 header file and header definitions in media-ctl utility.
http://git.ideasonboard.org/media-ctl.git
Related
I’ve found about file management explanations and file system explanations and “file system is part of file management” explanations. But I am wondering if they are the same or two different things? Because I cannot seem to find an article about them.
A modern Operating System, to be portable, must be file system independent. i.e.: It should not matter what type of storage format a given media device contains. At the same time, a media device must contain a specific type of storage format to contain files and folders, and at the same time be Operating System independent.
For example, an OS should be able to handle any file locally, allowing the actual transfer of these files from physical media to the OS (and visa-versa) to be managed by the file system manager. Therefore, an OS can be completely independent of how the file was stored on the media.
With this in mind, there are at least two layers, usually more, of management between the file being viewed and the file on the physical media. Here is a (simple) list of layers that might be used from top down.
OS App viewing the file
OS File Manager
OS File System Manager (allowing multiple file systems)
Specific File System Driver
Media Device Driver
When a call to read a file is made, the app (1) calls the OS File manager (2), which in turn--due to the opening of the file--calls the correct OS File System Manager (3), which then calls the Specific File System Driver (4), which then calls the Media Device Driver (5) for the actual access.
Please note that any or all could have a working cache manager which means calls are processed and returned without calling lower layers. e.g.: each read more than requested in anticipation of another read.
By having multiple layers like this, you can have any (physical) file system and/or media device you wish and the OS would be none the wiser. All you need is a media driver for the specific physical device and a file system manager for the physical format of the contents of the media. As long as these layers all support the common service calls, any format of media and content on that media will be allowed by the OS.
I'm trying to define the API for the REST paths of a new service where I have devices, and each device has a current location.
It needs a bit of background to understand the problem:
This is about pushing current device locations to a central server
Position updates are sometimes calculated on the device itself (GPS) and sent from the device (smartphone) to a server, but sometimes also via an external service (e.g. WiFi positioning system) and send from that system to a server
Each device has a unique id which the smartphone knows. The WiFi positioning system cannot know this id, it just knows the WiFi mac address.
Each device has several interfaces for position updates (mac addresses)
Regardless of where / from which interface location updates come, all location data should be linked to the same unique device id
So much for the background. Now about the API design. As mentioned above, I may get location updates where only the mac address is known, and I may get location updates where the unique device id is known. In both cases I can assume the id I get is unique and theoretically I can say that mac address x belongs to device y. Practically, this means I have a non-unique index to my location REST API:
For an example, consider I have a device with ID "123" and two mac addresses "abc" and "xyz". Commonly, my REST API path would group locations under the unique device:
/devices/$id/location
Now the problem is that there are multiple (unique) ids, each however related to one same device.
Like for example this would push a location by unique device id from the smartphone (where I know that unique ID, but do NOT know the mac address of the interface):
PUT /devices/123/location
And this is where an external system which only knows the mac address is pushing the location update using the mac address as key:
PUT /devices/abc/location
PUT /devices/xyz/location
You can assume that internally I can relate mac addresses and unique device IDs to one unique internal device. I could update and return location and device info using either a mac address and a device id.
For example the following GET requests using either the unique device id or unique mac will return the same location object:
GET /devices/123/location
GET /devices/abc/location
GET /devices/xyz/location
But is that a valid REST design where I can have multiple paths to the same resource? Should I rather change my REST paths, and how?
It might be useful to think about how you would design a web site that supports this behavior...
You might design that protocol this way: the client loads a known bookmark URI. Available in the representation of that page are two links, one for clients that know the mac address, a different link for those that know the identifier. The client would choose the appropriate link to follow. The representation returned by that would be a form, customized for the specific use case; the description of the form would specify the expected fields. The client would fill in the known fields (ignoring any unknown fields, which presumably have reasonable default values), and submit the form. The browser would use standard processing rules to produce the appropriate HTTP request to the action specified in the form.
In this case, where what we are interested in is (effectively) looking up the URI of the resource we want based on the information we have, we would normally use GET as the form method. That would send a query to the server, and from there the server can communicate (perhaps via re-direct) the appropriate URI to use for that device.
Once you've got the correct URI to use, GET/PUT/POST/PATCH/DELETE should all work as you would expect.
is that a valid REST design where I can have multiple paths to the same resource?
If the identifiers are different, then the resources are different. You are, of course, allowed to have more than one resource that expresses some concept (or, to put it another way, two different resources are allowed to share a single semantic mapping).
For your specific case, it would probably be OK to have a resource for clients that know the device by id, and another for clients that know the device by location. However, sharing a single resource identifier for both cases simplifies the server side caching story.
Part of the point of REST: if you define your media types and relations carefully, the server should be able to change the caching strategies used without breaking any clients (because the clients are just following links and submitting forms provided by the server).
We have a range of web applications here that allow users to download selected data from a number of databases and online services. Mainly Environmental information. We can track users visiting web pages using tools like Piwik or Google Analytics. We also want to track the amount of resource or data that they use, possibly also applying limits to record downloads.
If this was a single DB system we could track rows delivered within the db. However here we have a SOA with a range of sources and sinks. What I envisage is a service that can be messaged by other systems to register or track the amount of a resource used.
e.g User Andrew was sent 125MB of water quality data.
The central data metering service tracks usage messages from a variety of sources, produces reports and where appropriate applies caps or billing limits.
This service might be expanded to include processing as well as data download.
I would consider this to be a not unusual requirement but I can't find much in the way of existing software for it - perhaps because I am not using the correct terminology.
SO my questions:
What would you call this service - what keywords will lead me to existing systems?
What solutions already exist in this area - in particular FOSS or cloud based systems?
Could something like Google Analytics be persuaded to operate in this fashion?
It would be possible to do with the measurement protocol from Google Universal Analytics in conjunction with the user id feature in Analytics and one or more custom dimensions.
The measurement protocol is a language agnostic vaguely REST-like (inasfar as you send a bunch of parameters to an endpoint) protocol to send tracking data to the Google servers.
User id is a feature to recognize authenticated users across devices and multiple visits.
If the various parts of your setup send http calls build to the measurement protocol and include the user id to recognize the user and a value for a custom dimension for the file size (or rather a custom metric if you want to have sums and averages) and maybe a custom dimension for the file name you can send this to you Analytics account and build a custom report for downloads.
Note that the user id is an internal id that is used to link together visits by the same user from multiple devices - it is not something that shows up in the reports that would allow you to report on individual users in the Analytics interface (if you want that you need to include another id as custom dimension, and you have to check with the Google TOS what kind of id is allowed). Plus you'd need a dedicated data view in GA for sessions with a user id which will not show unauthenicated users.
our devices (microscopes with cameras) produce images and additional information to each image.
Now a middleware supplies wants to connect these devices to lab automation system. They have to acquire the data and we have to provide it. An astonishing thing for me was their interface suggestion - a very cryptical token separated format (ASTM E1394-97). Unfortunatelly, they even can't accomodate images in their protocol, and are aiming to get file-paths.
I thought it is not the up-to date approach. While lookink for alternatives, I saw CoachDB.
So, my idea was, our devices would import data including images in CoachDB and they could get the data. It seems even, that using mustache, we could produce the format they want (ascii-text) and placing URLs as image references instead of path's.
My question is, did someone applied CoachDB for such a use case already? It seems to be a little-bit misuse of CoachDB, as the main intention is interface not data storage. Another point disturbing me is, that the inventor of CoachDB went to other project Coachbase. Could it mean lack of support for CoachDB in the future?
Thank you very much for any insights and suggestions!
It's ok use-case and actually we're using CouchDB in such way - as proxing middleware between medical laboratory analyzers and LIS. Some of them publish images or pdf data on shared folders and we'd just loading them into related document as attachments.
More over you'd like to know, CouchDB is able to serve external processes (aka os_daemons) and take care about their lifespan: restarting if someone had terminated and starting right after you update config options through HTTP interface. This helps to setup ASTM client and server processes since this protocol is different from HTTP (which is native for CouchDB) which communicates with devices and creates documents as regular CouchDB clients. In same way you may setup daemons to monitor shared folders for specific files. And all this is just CouchDB with few "low bounded" plugins.
I`m currently developing a gwt application on a embedded device (linux with touchscreen) the server and client is started on the device.
I want my client to detect if it`s on the device or not. Because some screen are not available when connecting remotely
You can make a call to the server first and check there if it was made from remote or local address. A response from server should indicate if show screen "A" or not. Hope this helps.
Deferred binding might be the answer. GWT MobileWebApp sample app uses it to discern the form factor of the target in FormFactor.gwt.xml. In essence you define a property and write a provider which determines its value. You then read the property and deliver the appropriate View (in the MVP sense).
BTW I am developing an app for a similar scenario and I'm thinking of reimplementing my solution: reading a URL query parameter which is only present in the browser on the embedded device. Not too awesome. The aforementioned example should allow better hiding of the embedded platform identifier.