I was browsing through the capability of DIAL, and found out that it is very similar to UPnP, in-fact it uses UPnP protocol for device discovery (SSDP).
What dial is offering, actually a subset of UPnP protocol, isn’t it? Can't we use UPnP's SOAP for content sharing and communicating (launch app) instead of DIAL?
I'm not getting a clear picture where DIAL is fitting in the software stack (If I have UPnP supported already).
Please help me clear my confusion.
The new DIscovery And Launch (DIAL) standard builds on Universal Plug and Play (UPnP) but rather than trying to stream content from a device to the TV it asks the TV or set-top box to launch a suitable client to play back the content direct from source. That way, the digital rights management (DRM) issues are addressed while minimising the reliance in wireless bandwidth and removing the battery issue, but at the cost of creating a new standard.
More info here:
http://www.theregister.co.uk/2013/01/28/dial_youtube_netflix/
You are correct that UPnP could be used to accomplish what DIAL accomplishes.
DIAL apparently was developed quickly avoiding the UPnP standards development process. There was/is no reason that an UPnP device/service that implements application launch and has XML device/service description and SOAP actions could not be added to UPnP, and in fact there now is a UPnP multiscreen effort underway to do just that.
Advantages of DIAL: already defined; already being deployed; simpler than a UPnP device/service is likely to be.
Related
I would like to send a video stream via an ONVIF protocol from an a H.264 stream or an IP camera (which has not a onvif protocol).
I have seen that a programmer's guide exists but does a open code exists in java, C, javasript,etc?
Such a code does not exist, because the specification is in WSDL form, so you can use that to autogenerate the code with an adequate tool such as gsoap.
A note for comments
I am part of the ONVIF group, I used to be part of PSIA and took part to ISO/IEC TC 79 WG 12 for 62676-2. I can say that, unlike PSIA, there is not official code for device or client. Further more, implementations made by companies selling SOCs exist, but they require NDAs and are not opensource.
Since implementation depends on the operating system of the camera as well as on the software used to implement it and on the hardware, they are too specific. The tool used by most manifacturers is GSOAP. So please:
Understand that the WSDL specifications together with the programming guide is sufficient to develop it
Stop adding meaningless comments and/or suggest edits just to get badges.
I have an usb-camera with its drivers and dll with some functions to use this camera in my solutions. I want to use it in any wide-spread applications, to be able just to choose and use it in Skype, for instance. So. I want to develop something that will allow me to use this device as usual web-camera.
I've heard something about such technologies as "Upper-Level Filter Drivers" and "user-mode DirectShow source filter". Looks like it something that can help.
So the question is: what technologies exist for such tasks? What technology should I choose to solve my problem if I have no skills of driver development?
Skype still uses DirectShow for video capture and user mode filter will do the job. Still Skype makes certain unreasonable assumptions that limit compatible source filters, such as if the developers stopped development/testing as soon as they had their favorite USB cam working and ignoring all other devices users might possibly want to attach.
One of the options you were suggested (in Russian - 1, 2) was to develop a kernel mode driver so that your device is visible to apps through standard WDM Video Capture Filter. This is possible and would work, though in my opinion it is a huge overkill.
Fitting custom source filter is not easy because Skype does not like a debugger attached, however driver development is really a completely different story.
The Skype Forum link you refer to is clearly misleading. The poster complains that Skype update broke compatibility with video sources. And response from admin is about audio devices, and is irrelevant.
I'm looking to create a DLNA media server type of thing in Android. I've found myself a UPnP library for Java called CyberLink, and I'm looking to implement the DLNA interface for a M-DMS, or Mobile Digital Media Server, which has a quick description here:
http://www.dlna.org/dlna-for-industry/digital-living/how-it-works/dlna-device-classes/mobile-digital-media-server
The problem is that I can't find the actual technical specification for such a device. I've put in a lot of effort Googling, so please don't throw a 'JFGI' at me. I ran into a forum post that implied I might have to pay for access to the specification, but it was very vague:
http://www.ps3mediaserver.org/forum/viewtopic.php?f=4&t=3608
The link that was posted as the apparent solution is also broken, and I can't find any similar document on the current UPnP website.
Does anybody know where I can find the DLNA specifications? Or perhaps an alternative solution to implementing it myself? Any help will be much appreciated!
Full DLNA specs are available only to DLNA members and dearly paid for. The guy in referenced forum post is mixing things up. UPnP is not a "dlna doc". DLNA is a refinement of UPnP, a set of rules and restrictions in the name of interoperability. A good half of the DLNA specs is just a verbose listing of allowed media formats, subformats, sampling rates, bitrates etc. Whereas UPnP just specifies the abstract device interfaces. The link is correctly
http://upnp.org/resources/upnpresources.zip
and standardizeddcps is a subfolder there. DCP stands for Device Control Protocol, aka the abstract interface which the device must implement to participate in UPnP network. You would be interested in arch-DeviceArchitecture document to understand UPnP network in general and then MediaServer* folders, most importantly av-ContentDirectory which is a core service to provide DMS per DLNA specification. And yes, Intel Device Spy is absolutely essential tool. Wireshark will be your friend too. Reverse engineering is a daily bread and DLNA specs won't help you :)
The DLNA spec is now available to anyone -- you do not need to be a paying member to download.
From the DLNA.org website: (http://www.dlna.org/dlna-for-industry/guidelines)
Non-member companies may download the Guidelines using the form below.
**Please note that the Guidelines you download today are the most current published version of the DLNA Guidelines. When new Guidelines
are released, you will need to download the newer Guidelines to
receive the additional updates. Note that not all updates are
announced.
I'm not sure where to get the full DNLA specs but you could approximate the same info by using something like Intel Device Spy to see which services an existing M-DMS device publishes then use the service descriptions from the standardizeddcps directory in the docs available from the UPnP forum
You can get DLNA spec from the DLNA Organization, and for that you have to be member of the organization.
There is this DLNA compatible Digital Media Server (DMS) on Android platform and it is free for all Android platforms. It is tested with all leading DLNA certified TVs.
Pixel Media Server.
is there a way (hardware/software-combination) that I can use to control one or more "Philips Living Colors" lamps using a PC - e.g. a USB-stick that acts as the "remote". This way i could control the lamp through software (e.g. a web-app - over iPhone / remotely) or even create what Philips builds into some of their TVs and calls "ambilight" (graphics driver detecting the main color to control the lamp).
I guess this is more like a hardware than a software question - but I couldn't find anything about this online and I'm sure not to be the first to have come up with this idea right when I unpacked my LivingColors lamp yesterday ;)
There are two version of the LivingColors lamp, the Gen1 lamp can be controlled with a small kit, as far as i know the Gen2 can not be controlled with 3rd party products.
There is an Arduino shield that can control the Gen1 lamps, the article describing this is in Dutch. In short : the shield, and by extension the lamp, can be controlled by serial-over-USB. Google translate may help :
The hardware : http://www.knutsel.org/2010/04/11/assembling-the-cc2500-arduino-shield/
The link to the software is at the end of the post. (I can only post one link.)
There is a schema and software, enough information to build your own controller for Gen1 lamps.
Some remarks:
I am the a author of these posts.
The shields are sold as a kit in the Netherlands and Belgium (hence the dutch blog post).
The Gen2 uses IEEE802.15.4 (it says so in the manual) and is said to use encrypted Zigbee. Zigbee and encrypted Zigbee use IEEE802.15.4.
I should probably make a better translation of the posts.
[ 11 April 2010 edit : made translations of the blogposts in English and changed the links here ]
LivingColors uses an implementation of 802.15.4, the ‘ZigBee’ mesh-network wireless protocol designed for consumer appliances.
The second-gen LivingColors lamps can be persuaded to talk to the Philips Hue wireless bridge and integrate with a Hue setup. Much anecdotal information about how this is done can be had here:
http://www.everyhue.com/?page_id=38#/discussion/7/hue-and-living-colors
... for your purposes, integrating with Hue is your best bet, as the bridge exposes (as of yet, unofficially) a comprehensive RESTful JSON API, which is easily scripted — one of the better resources on using this API can be found here:
http://rsmck.co.uk/hue
I personally have had a good deal of fun doing what you are trying to do, with the Hue bridge and LivingColors lamps. Good luck!
I would too be interested by controlling my Living Colors from a computer, through a 2.4Ghz USB transmitter (mainly just for fun ;)
I have two Living Colors, a "Generation 1" and a "Generation 2", and the bad news is that the remote hardware and (maybe) the protocol have been totally modified by Philips in the process (probably to add the "fading effects" of the second generation). So it's even more complicated now, such a transmitter would have to deal with the 2 protocols.
Another link about what's inside the official controller
(in addition to the Elektor article given above) :
Gen 1 : http://www.knutsel.org/2009/01/01/livingcolors-1st-generation/
Gen 2 : http://www.knutsel.org/2009/12/01/philips-redesigns-livingcolors-breaks-compatibility/
Elektor (reverse engeneering of the procotol : http://www.ideetron.nl/Livcol/UK2008110661.pdf
I checked the Philips website where you can download the user documentation. The following trouble-shooting tip provides a clue:
LivingColors doesn’t respond quickly to the remote control.
- The communication between the remote control and the
LivingColors can be affected by heavy traffic on a wireless data
network, for example a wireless router.You should move Living-
Colors away from the wireless access point and switch your
wireless router to channels 8-11 for minimum interference.
So the controller uses wireless communication. It is clearly quite a sophisticated communication link, one controller can control up to 6 lights.
Unless it is a full WiFi link getting a computer to control the light would necessitate some heavy hardware hacking. Should it be a WiFi link it would be possible to write a driver.
If anyone has one these could they do a WiFi scan to see if the light and controller show up?
I am having big trouble to communicate through USB, from a Mac to an external HID device. The hardware has been proven fine when running under the Windows XP platform, but I can't find a GOOD exemple of programming the HID with Cocoa / objective-C. Several exemples are available in the Apple center, but they are either poorly documented, or too much complex ( in term of software with mixed objective-C and C, making the file difficult to understand), or not up to date. Well, I must say that I am more an hardware electronic engineer than a software specialist !
So far, I can enumerate the USB port, identify my device using the HID Apple's tools ( I read PID and VID ), but I miserably fail to send a report and/or to read a report back from the external device.
I would certainelly appreciate if one of you has used the new Apple's HID API and can share some know how.
On the other hand, is there any "USB spy" tool operating with the Apple's OSX ?
Thank you so much for your help
Michael
So yes, you're going to have to dive down and write C, not Objective-C, to do your thing.
Luckily, there's an additional Apple resource to make the USB/HID Manager MUCH easier.
See the HID Utilities Sample/Library from Apple
You are not going to find an Objective-c interface for the HID. At least, not anything more than a wrapper. Because of dynamic binding and delayed messaging, Objective-c is poorly suited to programming time dependent task like device drivers or for communicating with same. You're going to have to work in C.
The Apple resources: Accessing Hardware From Applications,the HID Class Device Interface Guide are going to be your best resources. This tech note offers a good overview as well.
The Apple System profiler will scan you USB chain to see what devices are visible to the hardware itself.
Edit01:
Can't believe I forgot about /Developer/Applications/Utilities/IORegistryExplorer. It gives you a detailed breakdown of the entire hardware tree.