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.
Related
I need a serial protocol for an embedded system that has some quirks. Right now it does YModem, but there are hiccups, so I thought I would try Zmodem or Kermit. Zmodem has both code and a clear enough implementation spec.
I can find nothing from which I can implement the file transfer protocol of Kermit from "scratch" (nor usable code).
There's source that isn't well organized and includes full terminal emulators and TCP clients, with all kinds of sections and options for every computer including antiques. E.g. C-Kermit 9.0. I'd spend more time refactoring it to extract just what I need than implementing it outright.
There is an abstruse mathematical paper that I find confusing since it doesn't talk about bits and bytes only something between a formal proof and pseudocode. (Proof.pdf - and it has theorems, proofs, and lemmas!). It claims to be some kind of specification. Maybe buried in there somewhere, but the same problem, I'd have to spend a while extracting the actual coding information.
I need some of the advanced features (full sliding windows), but the Embedded Kermit says it doesn't have those (though has some partial bits or hooks) but does have some other stuff I neither want nor need.
I don't think I would have any trouble writing Kermit from a real specification targeted to programmers as to what goes over the wire (content and timing), or better yet, a clean but full implementation.
I can't find either. Does anyone here know of one?
The kermit protocol was documented in the book Kermit, a File Transfer Protocol by Frank Da Cruz (Digital Press, 1987). There's an online document called Kermit Protocol Manual (1986), which I assume is an earlier version of the book.
Some of the optional features in the manual have never been implemented, and there are also some optional features that have been implemented but never found their way into the manual. If you're interested in these exotic extensions, you will need to browse through this archive of Kermit protocol discussions.
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.
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.
I want to try and make my own application for my Novation Nocturn, which is a USB DJ controller surface. The application software interacts with it to send out MIDI messages to software like Traktor, Ableton and Cubase.
I'm aware of libusb, but that's as far as I've got. I've successfully installed it to interact with my device but stopped there.
I'm after some suitable reading material basically. USB specs, MIDI specs and such. If I'm honest the full USB 2.0 spec looks like it holds loads of stuff I don't need.
Just looking for something interesting to do now that I've finished my degree (Computer Science). My current programming knowledge is C++ and mainly C#.
Could do with some direction on how to get stuck into this task.
edit:
Update to include some info from the Device Manager on the Nocturn.
Hardware IDs:
USB\VID_1235&PID_000A&REV_0009
USB\VID_1235&PID_000A
Compatible IDs:
USB\Class_FF&SubClass_00&Prot_00
USB\Class_FF&SubClass_00
USB\Class_FF
Device Class:
MEDIA
USB MIDI is probably one abstraction layer lower than you want to deal with. I'd suggest finding a good MIDI framework and interacting with the device via MIDI instead.
For C++, Juce is probably the way to go, as you didn't mention a target platform or any other specific requirements.
If you want to go the .NET route, the easiest way to get started is with the C# MIDI Toolkit code:
http://www.codeproject.com/KB/audio-video/MIDIToolkit.aspx
In there, you'll find all the basics for opening an device, reading input, and writing output. Alternatively, NAudio has some MIDI classes, but they are somewhat incomplete.
As you develop, you'll want a reference for the MIDI spec handy.
A tool that you will find invaluable is MIDI-OX. In fact, I suggest that before you start coding, you fire up MIDI-OX and use it to sniff the messages coming from the Novation. It will give you a good idea of what the Novation sends. You can use it in conjunction with MIDI Yoke (a configurable virtual MIDI port) to insert itself between the Novation, and Ableton Live (or whatever software you normally use with your Novation) so you can see all of the messages in normal use.
Done... Kidding, but I've started on this in Python - I personally want linux support. I am teaching myself python, but I only dabble in programming.
You can see basic functionality at https://github.com/dewert/nocturn-linux-midi. The guy who reverse engineered it (i.e. the leap I wouldn't have been able to make myself) doesn't seem to be doing any more with it. His code is at https://github.com/timoahummel/nocturn-game
I am using PyPortMIDI and PyUSB, both of which I believe are wrappers for the C equivalents. I think this is all ok on Windows, but haven't tried.
What is currently on my github is crap, but it is proof-of-concept. I'm working on doing it properly now, with threading and proper configuration options.
The driver for the Nocturn makes it appear to system as a MIDI device, even though it isn't a USB MIDI device at the hardware level. The Automap software works entirely at the MIDI level, receiving MIDI instructions and sending different instructions in response - it is separate from the driver and not neccesary.
Alternatively, look at https://github.com/timoahummel/nocturn-game for an example of talking to it directly over USB from Python. You can probably port this to another language with libusb bindings.
Old thread, but I've just recently started looking into this.
I had a look at the Python application that dewert has written. Interestingly, it turns out that the data that the Nocturn emits is in fact MIDI, although it doesn't register itself as a USB MIDI device.
But looking at the actual data coming from the device, it actually emits control change messages (0xB0 controller value) for everything. Also the control commands that are sent to it are also control change messages, albeit only the data bytes, as the Nocturn seems to support MIDI running status (i.e. when sending multiple control change messages, it is not necessary to repeat the data byte).
Indeed, the looking at the magical initialization data it is actually just a bunch of control changes: it starts with 0xb0 and from there on the data comes in twos. For instance the last two bytes in the init string are 0x7f 0x00 which simply turn off the LED for the rightmost forward button. (There is something subtle happening as a result of the initialization being sent though, as the Nocturn sometimes emits some messages which appear to be some form of timeout events, and that behavior changes depending on whether the initialization string has been sent or not.)
Using MIDI-like messages makes sense, as Novation would be well aware of the MIDI protocol, so it would be easiest for them to use it for the communication even if the device is not strictly a MIDI device.
Note though that the incrementors just send the values 1 or 127, i.e. +1 or -1 step, so even with some trivial mapping software it's not really useful as it is. (Actually, if turned quickly, one can get 3 or 125 for instance, with the 125 corresponding to -3.) The only controller which sends a continuous value is the slider, which emits an 8 bit value when moved.
I suppose you'll want to know about USB classes in general and USB MIDI class in particular. The latter is the best what you can hope for in case you don't posess documentation for some proprietary protocol (whether it's used there instead).
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.